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Preface 



This volume contains the proceedings of the 24th IFIP TC 6/WG 6.1 Interna- 
tional Conference on Formal Techniques for Networked and Distributed Systems 
(FORTE 2004), held in Madrid, Spain, September 27-30, 2004. FORTE denotes 
a series of international working conferences on formal description techniques 
applied to computer networks and distributed systems. The conference series 
started in 1981 under the name PSTV. In 1988 a second series under the name 
FORTE was set up. Both series were united to FORTE/PSTV in 1996. Three 
years ago the conference name was changed to its current form. The last five 
meetings of this well-established conference series were held in Beijing, China 
(1999), Pisa, Italy (2000), Cheju Island, Korea (2001), Houston, USA (2002), 
and Berlin, Germany (2003). 

The scope of the papers presented at FORTE 2004 covered semantic models 
and application of formal description languages (in particular, automata and 
Petri Nets), as well as the verification and testing of communication and dis- 
tributed systems. The conference was preceded by 2 half-day tutorials by Roberto 
Gorrieri and Farn Wang. The proceedings contain the 20 regular papers accepted 
and presented at the conference. They were selected from 54 submitted papers 
in a careful selection procedure based on the assessment of three referees for each 
paper. The proceedings also include the papers contributed by the three invited 
speakers: Martin Abadi, Tommaso Bolognesi, and Juan Quemada. 

FORTE 2004 was organized under the auspices of IFIP TG 6 by Universidad 
Gomplutense de Madrid. We would like to express our gratitude to the numerous 
people who contributed to the success of FORTE 2004. The reviewing process 
was one of the major efforts during the preparation of the conference, including 
not only PG members but additional reviewers. Finally, we would like to thank 
the local organizers for the excellent running of the conference. In particular, 
Luis Liana (as Web master), Natalia Lopez (as organizing chair), and Fernando 
Rubio (as publicity chair) deserve a special mention. Last, but not least, we are 
in debt to Richard van de Stadt, the author of GyberGhair, the tool we used to 
deal with the whole organization process. 

We would like to mention that this is the first time that FORTE had three 
colocated workshops: 

— TheFormEMG: 1st International Workshop on Theory Building and Formal 
Methods in Electronic/Mobile Gommerce 

— EPEW: 1st European Performance Engineering Workshop 

— ITM: 1st International Workshop on Integration of Testing Methodologies 

The proceedings of these workshops, which took place on the 1st and 2nd of 
October in Toledo, are also published by Springer in the LNGS series. 
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A Logical Account of NGSCB 



Martin Abadi* and Ted Webber^ 

'University of California at Santa Cruz 
^Microsoft Research, Silicon Valley 



Abstract. As its name indicates, NGSCB aims to be the “Next-Generation 
Secure Computing Base”. As envisioned in the context of Trusted Computing 
initiatives, NGSCB provides protection against software attacks. This paper 
describes NGSCB using a logic for authentication and access control. Its goal is 
to document and explain the principals and primary APIs employed in NGSCB. 

1 Introduction 

NGSCB (“Next-Generation Seeure Computing Base”, formerly known as 
“Palladium”) integrates hardware and software eomponents that aim to help in 
proteeting data and proeesses against software attaeks [8,9,14,15]. The hardware 
ineludes a eryptographie eo-proeessor that eontains keys and offers basie 
eryptographie serviees. The software ineludes new, trusted operating system 
eomponents. 

While the arehiteeture and the implementation of NGSCB eontinue to evolve, 
quite a few of its features have been diseussed in publie. We believe that it is 
worthwhile to elueidate them further. Many of these features seem likely to remain 
important as NGSCB matures, and also appear in other projeets and researeh efforts 
in the area of Trusted Computing [1,10,12,13,16]. 

In this paper, we present an attempt to understand the fundamentals of NGSCB in 
terms of a logie for authentieation and aeeess eontrol. This formalism had its origins 
in the eontext of the Taos operating system and of the Digital Distributed System 
Seeurity Arehiteeture [11,12,18]. In this applieation to NGSCB, we use the logie for 
deseribing relationships between prineipals while abstraeting away most of the details 
of the underlying eryptographie protoeols. Although it may be feasible and perhaps 
attraetive, we do not relate the logie to eonerete implementations, nor base new 
implementations on the logie. Our goal is to doeument the eomponents and primary 
APIs employed in NGSCB, and to provide eoneise and prineipled explanations for 
them. 

At present, one may view all work on NGSCB as “work in progress”. This paper is 
no exeeption. Beeause the speeifies of NGSCB remain subjeet to ehange, we are less 
eoneemed with giving a detailed and up-to-the-minute aeeount than with providing a 
eonsistent explanation of important eoneepts and teehniques. 

The next seetion reviews the logie. Seetion 3 reviews the basies of NGSCB. 
Seetions 4, 5, and 6 deseribe prineipals, derived authorities, and the eertifieation 
infrastrueture (whieh is external to NGSCB but neeessary for its applieations). 
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Section 7 deals with the main system services in logical terms. Section 8 briefly 
addresses privacy. Section 9 discusses an example. Section 10 concludes. 



2 A Brief Logic Review 

The logic enables us to describe a system in terms of principals and their statements. 
The logical formula P says s means that principal P makes or supports statement s. 
The principal may for example be a user, a piece of hardware, the combination of 
some hardware and some software, or a cryptographic key. 

We also allow compound principals, particularly of the form P \ C. The meaning 
of P I C is “P quoting C”; we have that P \ C says s when P says that C says s. For 
instance, P may represent a piece of hardware, and C a piece of code or a user. 

In addition, the logical formula P => g means that P speaks for Q, so if P says s 
then Q says s, for every We generally assume the hand-off axiom which says that if 
Q says P => Q then indeed P ^ Q. We use the “speaks for” relation for many 
purposes. For instance, we often write that a key K speaks for a principal P when K is 
P's public signature key. Typically only P knows the corresponding signing key (Ws 
inverse) and can produce signatures that can be checked with K. We may also write 
that a principal speaks for any group of which it is a member; thus, when we write 
that P speaks for a group we typically mean that P is or speaks for some member of 
the group, not necessarily all members of the group. (It would be easy to extend the 
logic with a membership relation, and to replace “speaks for” with membership in 
these uses; whether this extension is worth the trouble remains open to debate.) We 
may represent an access control list (ACL) as the group of the principals authorized 
by the list. If G^is the ACL for accessing an object A, thenP speaks for Gx when P is 
authorized to access X. 

Although the logic does not lead to correctness proofs of the kind expected in 
high-assurance systems, this logic and its relatives have been useful in several ways 
in the past. Much as in this paper, the logic has served for describing and 
documenting the workings of a system, what the system achieves, and on what 
assumptions it relies, after the fact or in the course of development. In this respect, 
formal notations do not accomplish anything beyond the reach of careful, precise 
prose, but they are helpful. The logic has also served in validating particular 
techniques for authorization, reducing them to logical reasoning, and also as a basis 
for new techniques; research on stack inspection and proof-carrying authorization 
exemplify this line of work [3,6,17,18]. Finally, the logic has served as a foundation 
for languages for writing general security policies [7]. 

We refer to previous papers for more detailed descriptions of the logic and its 
applications. 



3 Assumptions on NGSCB 

We assume that at the root of any NGSCB node there exists a hardware-based 
security facility that implements cryptosystems, random number generation, and key 
storage. We use the term Security Support Component {SSC) to describe this facility 
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since it has been previously used in related literature. The Trusted Platform Module 
(TPM) from the Trusted Computing Group [16] may be the main current example of 
an SSC. 

We further assume that the hardware has the capability to load an operating system 
that can be reliably identified by taking a hash (or code-id) of the initial operating 
system image and data. This operating system, so loaded, will reside in a protected 
area of memory that cannot be accessed by untrusted code that the operating system 
might load. Therefore, the hardware has reason to believe that the statements made by 
the securely loaded operating system can be attributed to the principal identified by 
the code-id. In turn, the operating system can load a child process and attribute 
statements made by that child process to the principal identified by the hash of its 
code and data. Following one existing nomenclature for NGSCB, we call the securely 
loaded operating system the Nexus, and we call any child process that it loads a Nexus 
Computing Agent {NCA). The Nexus may be implemented, for example, by 
combining a virtual-machine hypervisor with a trusted guest operating system 
[10,15]. For simplicity, we focus on situations with one distinguished Nexus and one 
distinguished NCA; of course, other software may be running on the hardware at the 
same time. 

Finally, we assume trusted input and output paths for communication with users. 
In particular, the hardware may guarantee that only a particular Nexus receives input 
from the keyboard and can send output to a display. The Nexus may in turn provide a 
similar guarantee to a particular NCA. 

These assumptions are consistent with previous, public descriptions of NGSCB, 
such as the ones found in papers and on the Web. Those descriptions, like most 
informal descriptions, are however incomplete and imprecise in some respects. One 
of the goals of the present logical account is to complement those descriptions, with 
additional details (some of them validated in private conversations with the NGSCB 
team, and some of them conjectured rather than based on an official NGSCB design), 
and with a partial rationale for the workings of NGSCB. 



4 Principals 

Next we enumerate principals relevant for NGSCB security. 

The following principals are particular to each NGSCB node. Each node will have 
different instances of them. 

K(j the permanent public key of the SSC 

Kt a per-boot public key of the SSC 

So the master symmetric key of the SSC 

St a per-boot symmetric key derived from So 

The inverse of the key Ko and the symmetric key never leave the SSC hardware; 
the inverse of the key Kt and the symmetric key St may or may not leave the 
hardware, as discussed below. We rely on asymmetric cryptography (public -key 
operations with Kq, Kt, and their inverses) primarily for digital signatures, rather than 
for public -key encryption. When encryption is needed, we indicate it explicitly. The 
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symmetric key So may be replaced with a pair of keys for asymmetric encryption, 
with only minor changes. 

The following principals represent software images. There can, of course, be many 
different images in which we might be interested. For simplicity of exposition, we 
will be concerned with only two: 

Cnex the code-id of a particular Nexus 
Cnca the code-id of a particular NCA 

The following principals complete the cast; they provide the context outside an 
NGSCB system: 

M a manufacturer of SSC hardware 

V a vendor or author of Nexus software 

A a vendor or author of NCA software 

Km M's public signature key 

Ky Fs public signature key 

Kyi A's public signature key 

Gm a group of public signature keys for SSCs produced by M 

Gr a group of code-ids for Nexus software images produced by V 

Ga a group of code-ids for NCA software images produced by A 

CA a trusted certification authority 

5 Derived Authorities 

It would be possible for an SSC to make statements only with its permanent public 
key Kq. Flowever, it is desirable to sign as few certificates as possible with this key. 
Therefore, we assume that, at boot time, the SSC generates a temporary key pair, 
consisting of the public key Kj and its inverse. Then ifo transfers all of its authority to 
Kj-. This hand-off of authority is captured in the following statement: 

Kg says Ky Kg 

The certificate described here, and all subsequent certificates mentioned in this 
paper, should be considered valid only for a limited period of time. The logic does not 
directly model time, so we do not represent time formally; one could probably add it 
with a modest effort. 

In this formulation, we assume that the SSC holds the temporary secret key (the 
inverse of Ky) in hardware and uses the key for signing statements on behalf of other 
principals on the local machine. This key could instead reside in the Nexus and be 
accessed through a similar interface. In this case, the key would no longer be 
protected within the SSC, so the two arrangements entail different security properties. 

Because of the secure loading steps described above, a successfully loaded Nexus 
will have the authority of the compound principal Ky \ Cnex- An SSC can run any 
Nexus software, but the rights of a specific Nexus instance are exactly those of the 
SSC parameterized by the code-id of the Nexus. Similarly, an NCA loaded on top of 
a Nexus would speak as Kj \ Cnex I Cnca- 
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6 Certification Infrastructure 

In order to deduce anything useful about statements made by the software running on 
an NGSCB node, we must have trust assumptions. We hypothesize the presence of a 
certification authority CA that makes statements that are globally trusted. In 
particular, we trust CA to specify the set of acceptable NGSCB nodes and the set of 
trusted Nexus and NCA software images; we express this trust as follows: 

CA^Gm 

CA^Gv 

CA^Ga 

We simplify a bit here: in practice, CA will almost always be implemented by a 
hierarchy of certification authorities and there will be multiple subgroups of Gm, Gy, 
and Ga, according to the intended applications and trust relationships. 

Next, we must give some key (or set of keys) the authority to certify membership 
in the groups Gm, Gy, and Ga- We represent such statements in the following 
certificates: 

CA says Km ^ Gm 
CA says Ky^ Gy 
CA says Ka => Ga 

Finally, we use the signing keys that correspond to Km, Ky,_ and Ka for making 
membership certificates for the specific hardware/software stack that we intend to 
construct: 

Kusays Kg^ Gm 
Kysciys Cnex"^ Gy 
Ka says C^ca Ga 

Combining the certificates and trust assumptions, we can derive: 

Kg => Gm 
CneX=> Gy 
Cnca => Ga 

Note that if Kg is a member of Gm (so Kg => Gm in our model) then Kg can also 
define new group members of Gm- In particular. Kg => G^and Kg says Kf => Kg imply 
that Ky ^ Gm- Using a primitive membership relation rather than “speaks for” would 
remove this possibility. 



7 Programmatic Interface 

The programmatic interface of NGSCB supports the sealing of information and 
hardware-based attestation. Next we explain those functions in terms of the logic and 
of the definitions of the previous sections. 
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7.1 Sealing 

Seal(X,C). The Seal funetion stores the data X in sueh a way that it ean be retrieved 
later by the same SSC, and only by that SSC. Furthermore, a eode-id C is bound into 
the result so that the SSC ean restriet subsequent aeeess to that eode-id. For example, 
an NCA might seal data under its own eode-id for later retrieval, or the Nexus might 
seal data under the code-id of a subsequent Nexus version as part of a version 
migration strategy. The sealed data might be private user information, and the goal of 
the sealing might be to protect this information from viruses on the same machine. 

Sealing amounts to setting up an access control rule, which we model with the 
following statement: 

So says C ^ Gx 

This means that the hardware asserts that C is a member of the group Gx of 
principals that can access an object with the data X. Nothing here precludes the 
possibility that other objects also contain the data X and that code other than C may 
access those objects. 

In practice, the SSC does not store the data, but rather encrypts it with its private 
key and returns the sealed data item. Here we can use the symmetric key So instead of 
Ko since the statement is always evaluated in the context of the local machine. So this 
kind of sealing can be accomplished through authenticated encryption using 
symmetric ciphers and message authentication codes (MACs). 

In order to limit the exposure of So, the use of a per-boot symmetric secret, St, 
might be desirable. (Indeed, the TPM design goes further in permitting chains of 
intermediate keys.) Suppose that we generate a per-boot nonce, N, and derive St as a 
function of So and N for example by setting St = HMAC(5o,A^. This definition 
implies that N must be stored in plaintext with the sealed content in order to allow the 
recovery of St In the logic, the access control rule for the sealed object can be 
expressed with the following statements: 

So says St So 

St says C =>Gx 

The Seal function might be offered to NCAs by the Nexus, or NCAs might be 
given direct access to the SSC's Seal function. In the former case, a symmetric key 
held by the Nexus would be used for sealing instead of St- This design has the 
advantage of allowing more straightforward migration to different hardware, but the 
disadvantage of exposing temporary keys within the memory system. 

Unseal(X,C). The Unseal function retrieves data held under seal. Conceptually, 
access to the sealed data is granted on the basis of the result of evaluating the 
corresponding ACL using the code-id of the caller. When Seal relies on encryption, 
the SSC implements Unseal by decrypting data that it previously sealed under its own 
secret. 

PKSeal(X,K). The PKSeal function is similar to Seal except that a target key K is 
used instead of a code-id. In this case the unsealer is not assumed to be the same SSC 
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as the sealer. Therefore, PKSeal can be used to seal data for retrieval on another 
machine. 

We can describe PKSeal by an access control rule, much as we did for Seat 

Kt says Gx 

If PKSeal is implemented by placing X on a storage server operated by a trusted 
third party, then the certificate Kj says K => G^can be directly useful as input to the 
reference monitor on that server: when K requests access to X, the reference monitor 
grants it. 

Alternatively, as its name suggests, the implementation PKSeal can perform 
public-key encryption on X. For this purpose, the public key K should be an 
encryption key (and not just a key for checking signatures). 

PKUnseal(X,K). Much like Unseal, PKUnseal implements the corresponding access 
control rule. When PKUnseal relies on encryption, the implementation of VYJJnseal 
relies on decryption. In this case, whoever holds the inverse of the public key used for 
sealing will have de facto access to X. 

7.2 Attestation 

Quote(ST). The Quote function allows the SSC to attest to statements made by 
principals under its control. For example, the SSC may attest that a particular, trusted 
application (not a virus) is making a request to write a file. 

Suppose that an NCA wishes to utter the statement ST and have the SSC attest to 
this statement over a network. As described in Section 5, the NCA speaks with the 
authority: 

Kt I CffEx I CxcA 

Since only cryptographic keys can securely make statements over an otherwise 
unprotected network, the SSC encodes the uttered statement as: 

Kt says ( Cxex \ Cxca says ST) 

According to the definition of quoting in the logic, this formula can be written 
more straightforwardly: 

Kt I Cmx \ Cnca says ST 

In particular. Quote can be used to attest that a key speaks for a principal. For 
example, suppose that an NCA wishes to indicate that a key K is authorized to make 
statements on its behalf In this case, the quoted statement ST is: 

K =^Kt I CxEx I Cnca 

and the certificate that the SSC would form in order to attest to this hand-off of 
authority would be: 

Kt says ( Cnex \ Cnca says (K =>Kt\ Cnex \ Cnca)) 



which reduces to: 
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Kt I Cf^Ex I CffCA says K =>Kj-\ C^ex I Ovet 

Here the key K may be a publie key, but it may also be a symmetrie key that 
underlies an authentieated eommunieation ehannel from the NCA. 

This kind of quoting might be used by the Nexus direetly as well. In this ease, the 
SSC would produee: 

Kt says ( Cmx says K =>Kj\ Cmx) 

whieh implies: 

I Ceiex says Kf\ C^ex 

Verify(ST). The Verify funetion must deeode a statement generated by Quote and 
eheek the eonsisteney of its eryptographie evidenee. Furthermore, the results of 
Verify should enable reasoning about the prineipal that made the statement in 
question. 

Often, the reeeiver of a statement interprets the statement in a different trust 
environment (and in a different maehine) than the sender. The reeeiver must eome to 
eonelusions based on its own trust assumptions. For example, if the reeeiver sees: 

Kt says ( Cmx \ Cmca says ST) 

and believes: 



Kfi says Kj => Kg 

then the reeeiver ean eonelude: 



Kg I CffEx I Cf/cA says ST 

Suppose that the reeeiver has the eertifieates and trust assumptions introdueed in 
Seetion 6. Then the reeeiver ean deduee: 

Gm \Gv\Ga says ST 

The reeeiver may trust Gm \ Gy \ Ga on ST. For example, when ST represents a 
request for aeeess to an objeet X, the ACL for X may inelude Gm \ Gy \ Ga, granting 
aeeess to a member of Gm quoting a member of Gy quoting a member of Ga- (In other 
words, the reeeiver may have that Gm \ Gy \ Ga ^ Gx-) Thus, the reeeiver ean reason 
about the prineipal that said ST and use the identity of that prineipal as the basis for 
aeeess eontrol deeisions. 

8 Privacy 

It may be undesirable for all eertifieation ehains assoeiated with the statements from a 
given SSC to be rooted at a single key Kg. If this were the ease, then an observer 
might be able to traek the aetivity of speeifie maehines and use this information to 
eompromise user privaey. In light of sueh eoneems, several privaey-enhaneing 
meehanisms have been developed. 

Upon boot, the Nexus might eommunieate with an anonymization serviee that 
would be trusted to issue semi-permanent key pairs to trusted system eomponents. 
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and also trusted to respect privacy. In this case, the Nexus carries out a secure 
transaction with the anonymization service, using the authority Kj- \ Cmx- After 
establishing that Kt \ Cmx => Gm \ Gy, the service returns a collection of public keys 
Ki, their inverses, and certificates of the following form: 

K anon says Kj => Gm \ Gy 
CA says Kan on => Gm \ Gy 

where Kanon is the public key of the anonymization service. The inverse of any key 
Ki can be used by the Nexus to sign subsequent statements. Since neither Ki nor Kanon 
are linked to any single user, SSC, or Nexus, this indirection provides some 
anonymity for the holder of the inverse of if,. 

Variants of this scheme can provide keys if, that speak for G^or for Gm | G^- | G^ 
(rather than for Gm \ Gy). The inverse of a key that speaks for Gm should not be under 
the control of the Nexus; therefore, the anonymization service should return the key 
sealed in such a way that only the SSC itself can access it. 

More sophisticated schemes rely on group cryptography [2,4,5]. Using group 
cryptography, an SSC may issue signatures that cannot be distinguished from 
signatures generated by some set of other SSCs. Instead of Kg, each SSC has a share 
of the group key Kj^/ode-group- The manufacturer M makes Km says Kj^/ode-group => 
Gm- Then the SSC can produce a certificate for a temporary key Kf. 

KNODE-GROUPSayS Ky => KfiODE-GROUP 

Although this certificate does not identify a particular SSC, shares of the group key 
can be revoked; the specifics of revocation vary across schemes. 



9 An Example 

In this section we exercise the logic on a practical example of an application of 
NGSCB, due to Butler Lampson and Paul Leach. In this application, an NCA 
presents an image (perhaps of a sales order or an online-banking transfer) to the user 
of a machine, and attests to the fact that the user clicked “OK” to accept the 
consequences implied by the image. For this application, we have to assume that 
there is a trusted path between the NCA and the keyboard and display in front of the 
user. We also assume that an untrusted banking or purchasing application is running 
(perhaps in a web browser) on the user's machine outside the context of NGSCB. 
This untrusted application uses the trusted NCA to carry out security-critical aspects 
of online transactions directly with the merchant or bank. 

There are many different protocols that could support this sort of scenario. We will 
assume a simple model in which the NCA establishes an authenticated channel to a 
bank, and uses that channel to assert that a specific user has confirmed the contents of 
a specific image. For these purposes, we assume that the user can present a password 
known to the bank. 

Although the Nexus and NCA might depend on an untrusted operating system to 
communicate with the network, the cryptography used to establish and maintain a 
secure channel can be implemented within a trusted NCA. Let us say that the NCA 
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establishes an SSL ehannel to the bank and authentieates the bank using a eertifieate 
ehain in the usual style. The NCA ean also authentieate itself to the bank in that SSL 
exehange. In the logie, this authentieation ean be written as: 

Kt I CtiEx I Cnca says Channel => Kt \ Cmx \ Cjvca 

where 



Ko says Kj Kg 

Mueh as in Seetion 7.2, the bank ean now deduee that Channel speaks for a trusted 
NGSCB node running a trusted NCA. Using Channel or by other means, the bank ean 
transmit an appropriate image for the user to aeeept. The image is reeeived by the 
NCA and shown on the user's display via the trusted path to the hardware. Perhaps 
the target window is distinguished with a speeialized border that indieates seeured 
images of this form. If the image is aeeeptable to the user, then the user is asked to 
provide a password and eliek “OK”. Gathering this input on the trusted path from the 
keyboard, the NCA ean now make the following statement on the trusted ehannel to 
the bank: 



Password says OK-Image 

Here, the image might be represented by its hash. If all is in order, the bank ean 
deduee: 



then 



Channel \ User says OK-Image 



and henee 



Ko I Cmex I Cnca I User says OK-Image 



Gm \ Ge\ Ga\ User says OK-Image 

Now the bank may eonelude that the user (or at least an NCA holding the user's 
password) authorized the eonsequenees represented by Image. Furthermore, the bank 
may also eonelude that the transaetion took plaee over a ehannel from a trusted 
NGSCB node and a trusted NCA. 

The bank may impose restrietions on the set of maehines and software that ean 
serve as origin of the ehannel. These restrietions may thwart eertain types of attaeks. 
For example, even if the password is eompromised, it eannot be used direetly by just 
any applieation. 



10 Conclusion 

This paper deseribes NGSCB in terms of a logie for authentieation and aeeess 
eontrol. Its goal is to doeument and explain NGSCB's prineipals and primary APIs. It 
aims to eomplement previous deseriptions of NGSCB, with additional design 
elements, and with a (partial) formal rationale for the workings of NGSCB. 
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As discussed in the introduction, NGSCB is still “work in progress”. We will not 
venture predictions on its future evolution or applications. It is possible that some or 
all of the features of NGSCB described in this paper will change. That represents a 
risk, but an inevitable one whenever one applies formal techniques in the course of 
the development process. We believe that, in any case, those features and their 
principles will be valuable beyond the context of NGSCB. 
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Abstract. Event-based process algebraic specification languages sup- 
port an elegant specification technique by which system behaviours are 
described as compositions of constraints on event occurrences and event 
parameters. This paper investigates the possibility to export this specifi- 
cation paradigm to a state-based formalism, and discusses some deriving 
advantages in terms of verification. 



1 Introduction 

Process-algebraic specification languages have received much attention in the 
eighties and nineties, with emphasis, in the first decade, on theoretical founda- 
tions and semantics, and with various experiments and projects, in the second 
decade, for their application to the development of large-scale software systems. 

Many people involved in software production, and several researchers from 
academia as well, agree today in observing that most of the early, ambitious 
goals of process algebra have not been met. The diffusion of process-algebraic 
languages within software companies, as a routine tool for design and verification 
activities, is quite limited. 

Process-algebras and related methods represent just a portion of the articu- 
lated area of Formal Methods (FM). It is fair to admit that, so far, FM’s in gen- 
eral have gained only limited acceptance in industry. Typically, they are applied 
in the development of safety-critical (sub-) systems, for which formal verification 
becomes crucial; but their popularity does not compare with that reached by 
more ’practical’ approaches such as the object-oriented UML. 

The reasons for these difficulties have been already discussed quite extensively 
in the past; we only mention, below, those that have more directly motivated 
the work presented in this paper. 

— The offer of FM’s appears still too wide and fragmented. The WWW Virtual 
Library on Formal Methods, as of today, provides a list of 92 individual no- 
tations and associated tools (http://vl.fmnet.info/#notations). While some 
techniques are fairly stable, others keep evolving, and new ones appear, al- 
though less frequently than in the past; making choices in such a wide and 
dynamic set is hard, also considering the high training costs associated with 
the adoption of a FM. 
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— ’Political’ concerns and parochial attitudes have often obstructed the recog- 
nition of similarities among formal languages and the convergence towards 
fewer stable proposals. FM’s would greatly benefit from some unification ef- 
fort, as it happened with the definition of the Unified Modelling Language. 
Some steps in this direction have been already taken, as indicated, for exam- 
ple, by the recently established Integrated Formal Methods (IFM) series of 
international conferences, by the work on the Unified Theories of Program- 
ming [1], and by proposals such as Circus [2], but much remains to be done, 
also in the sense discussed in the next bullet. 

— Perhaps more specifically in the area of process algebraic FM’s, there has 
often been a mismatch between the offers from FM developers, and the real 
needs of perspective FM users, with the former emphasizing on the meta- 
level of formal semantic definition, on axiomatisations, on countless semantic 
relations, and the latter emphasizing on ease of use, expressive flexibility, 
pragmatic guidelines, tool support. The well known work on Design Patterns 
is an important factor for the wide acceptance of Object Oriented technology 
(note that patterns are language-independent!): this is, again, a lesson from 
0-0 technology that the FM community might want to take into serious 
consideration. 

Formal approaches to the behavioural specification are often partitioned into 
state-based (e.g. Abstract State Machines [3, 4], B [-5], TLA [6, 7], or Z [8]), usu- 
ally rooted in logics, and event-based (e.g. CSP [9], CCS [10], or LOTOS [11, 12]), 
with algebraic roots. Today, software engineers seem to look more favourably at 
state-based FM’s: they better relate with other traditional and well understood 
engineering methods, they have proven to be quite effective in hardware de- 
sign, and they lend themselves to increasingly effective analytical techniques. 
And yet, event-oriented thinking keeps playing an important role, at least in the 
early phases of system development; for example, use case diagrams, scenarios, 
message sequence charts are widely used in requirements analysis. 

This paper is an attempt to promote some cross-fertilisation and convergence 
in the area of FM and, in particular, between the event-based and state-based 
specification paradigms: in line with the remarks above, we wish to address as- 
pects of language pragmatics, namely specification style, structuring principles, 
and tool-supported verification, rather than semantic foundations. 

Fifteen years have passed since the publication of the LOTOS specification 
of Al’s Node by Quemada and Azcorra, [13] which has represented a tiny but 
very effective example of the so called ’Constraint-Oriented’ specification style. 
We believe that, while several results of theoretical interest from process algebra 
have failed to scale up to realistic-size system development, some expressive tools 
from this area of FM’s have shown to be very effective. We wish to list three of 
them, in order of increasingly complexity: 

— The basic notion of ’event’. This is an abstraction that process-oriented 
specification languages regard as equally important as the notion of ’state 
variable’, but conveniently distinguished from it. 
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— Parallel composition operators. These are the most typical among the ad- 
hoc, high level behavioural operators of process algebras. In particular, se- 
lective synchrony (i.e., the general LOTOS parallel operator ’|[5']|’, where S 
is a list of synchronization gates), fundamentally based on the gate/event 
concept, is crucial for compactly specifying interaction patterns simultane- 
ously involving interleaving and synchronized events from different system 
components. 

~ The constraint-oriented specification style mentioned above. This way of 
structuring specifications is in turn based on the use of the selective syn- 
chrony parallel operator. 

In this paper we investigate the extent to which the three expressive tools 
above, typical of process-algebraic specification, can be imported into state-based 
specification. For fixing ideas, we select one representative language from each 
paradigm: we choose LOTOS and TLA-I-. For space reasons, we have to assume 
some familiarity with both of them, but the uninitiated reader should still be 
able to follow our discussion on specification structuring principles, without being 
distracted by the details of the two concrete languages. 

The key question addressed by the paper can be summarized as follows. 

— Assume you want to adopt a state-based formalism such as TLA-I- for spec- 
ifying systems, being attracted by: 

• the simplicity and universality of its constructs, which are based on first 
order logic, and on few temporal logic operators - no need to learn ad- 
hoc, process-algebraic behavioural operators; 

• the conceptual simplicity of the verification technique it supports (im- 
plementation is pure logical implication); 

• the free availability of tools (most notably, the model checker TLC) . 

— Assume also you have an inclination towards structuring some behavioural 
specifications as collections of constraints insisting on partially overlapped 
sets of events (deriving from a possibly unconfessed past experience in the 
community of ’LOTOS-eaters’). 

Should you give up your way to conceive specifications? In this paper we try to 
justify a negative answer to this question. 

In Section 2 we recall Al’s Node, we introduce two abstract, monolithic formal 
specifications of it, in LOTOS and in TLA-I-, and show one way to model ’events’ 
in TLA-I- . 

In Section 3 we address constraint-oriented specification. We show that the 
behaviour of Al’s Node can be conveniently expressed in terms of three con- 
straints, and that their interplay can be compactly expressed in LOTOS. We 
then illustrate two ways in which we can approximate that structuring in TLA-I- . 

In Section 4 we take advantage of the translations into TLA-I- by conducting 
some verification activity. We prove, by the TLC model checker, that the two 
TLA-I- constraint-oriented specifications of Al’s Node are equivalent, and that 
they implement the initial, monolithic specification. 

In Section 5 we present our conclusions and identify items for further work. 
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2 Event-Based, Monolithic Specification 

In this section we introduce Al’s Node by providing an informal, monolithic (one 
process) description and a formalisation in LOTOS. We then illustrate a very 
similar formalization in TLA+, based on a simple idea for preserving the no- 
tion of observable event. This TLA-I- specification provides the reference against 
which the subsequent, structured, constraint-oriented TLA-I- specifications are 
formally verified. 

2.1 Informal Description of Al’s Node 

Al’s Node is a switching device for controlling message traffic in a network. The 
node keeps the following data structures: 

— a bag of messages, 

— a set of active ports, 

— a set of {route, port) pairs, defining the active routings. 

Messages can be accepted by the system at any active port, and stored in the 
node. An incoming messages consist of a {data, route) pair: the data item has to 
be re-directed to the associated route. Stored messages can be lost, or output, 
not necessarily in FIFO order, at some active port that is paired, according to 
the current active routings, to the route indicated in the message. 

For keeping specifications concise, and in accordance with the original exam- 
ple, we allow elements to be only added to, not removed from the set of active 
ports and the set of {route, port) pairs. We omit the treatment of timeouts. 

2.2 Monolithic Specification in LOTOS 

The LOTOS specification makes use of three predefined sets: Data, Ports, Routes. 
For representing data structures we depart from the LOTOS standard, and use 
plain mathematical structures; besides being more convenient, they can be re- 
used in TLA-I-. The specification consists in a single process, called AlsNode- 
Monol. This process insists on gates DATA_IN, DATA_OUT, DATA_LOSS, 
CTL, and is parameterized by the three variables: 

msgBag: a bag of {data, route) pairs, of size at most N, 
activePorts: a set of Ports, 
activeRoutes: a set of {route, port) pairs. 

Process AlsNodeMonol is structured as a set of alternatives, each consisting of 
an event, controlled by a guard (a ’selection predicate’, in LOTOS terminology), 
and followed by a recursive process instantiation with updated parameters. In 
the specification we omit gate lists in recursive process instantiations: they are 
the same that appear in the enclosing process definition. We use symbol ’(-I-)’ 
for bag union and ’(-)’ for bag subtraction. 
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PROCESS AlsNodeMonol 

[DATA_IN, DATA_0UT, DATA_L0SS, CTL] 

(msgBag: BagOf (Data x Routes), 
activePorts: SubsetOf (Ports) , 
activeRoutes : SubsetOf (Routes x Ports)) 

DATA_IN ?d: Data ?r: Routes ?p: Ports 
[p in activePorts, Size (msgBag) < N] ; 

LET msgBag’ = msgBag (+) -[<d, r>}- IN 

AlsNodeMonol [ ] (msgBag’, activePorts, activeRoutes) 

[] 

DATA_0UT ?d: Data ?r: Routes ?p: Ports 

[p in activePorts, <d, r> in msgBag, <r, p> in activeRoutes)]; 

LET msgBag’ = msgBag (-) -[<d, r>}- IN 

AlsNodeMonol [ ] (msgBag’, activePorts, activeRoutes) 

[] 

DATA_L0SS ?d: Data ?r: Routes [<d, r> in msgBag]; 

LET msgBag’ = msgBag (-) -[<d, r>]- IN 

AlsNodeMonol [ ] (msgBag’, activePorts, activeRoutes) 

[] 

CTL ?p: Ports [p notin activePorts]; 

LET activePorts ’= activePorts union -[p]- IN 
AlsNodeMonol [ ] (msgBag, activePorts’, activeRoutes) 

[] 

CTL ?r: Routes ?p: Ports [<r, p> notin activeRoutes]; 

LET activeRoutes ’= activeRoutes union l!<r, p>]- IN 

AlsNodeMonol [ ] (msgBag, activePorts, activeRoutes’) 

ENDPROC (* AlsNodeMonol *) 

The interpretation of the events at the process gates is as follows. An event at 
gate DATAJN, with parameters {d, r, p) represent the input of message {d, r) 
at port p. Events at gate DATA_OUT have a similar interpretation, while those 
at DATA_LOSS do not need a port parameter. Gate CTL is used only for adding 
elements to activePorts and activeRoutes. The complete set of possible events is 
explicitly defined in TLA-I- module AlsNodeInterface in the next subsection. 

2.3 Monolithic Specification in TLA+ and Event Representation 

A monolithic specification of Al’s Node in TLA-I- with the same structure of 
the above LOTOS specification can be provided quite easily, since the latter 
matches a state- oriented style, and makes use of a restricted number of operators, 
namely action prefix with guards^ choice and process instantiation. We only have 
to decide about the representation of events. TLA-I- does not offer a primitive 
notion of event. It offers actions. A TLA-I- action is logical formula that includes 
primed and unprimed variables, and may or may not be satisfied by a step. 
A step is a pair of successive states. A state is an assignment of values to all 
state variables. 
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LOTOS events occur at gates. A gate is a location at which processes atom- 
ically synchronize and agree on tuples of values. A gate cannot be assimilated 
to a normal state variable because it is intrinsically unable to retain any value. 
Processes may be thought of as writing values at gates, but these values are 
immediately lost. They can only be retained by using local process variables (as 
in ’?d: Data'). 

Thus, we model events in TLA-I- by a write-only state variable that we con- 
ventionally call e, and that shall only appear in primed form in action predi- 
cates, so that it never contributes to pre-conditions. Event e shall be a tuple (or 
a record), in which the first component is a sort of event type, and is the equiv- 
alent of a LOTOS gate identifier, while the remaining components represent the 
event parameters. The advantages of introducing the special event variable be- 
come more apparent with constraint oriented specification, as discussed in the 
next section. 

A TLA-I- specification is formed by a set of modules. Our first module, pre- 
sented below, is called AlsNodeInterface. It introduces the basic components of 
the specification, that shall be imported by the subsequent TLA-I- specifications. 
The interface introduces the node capacity N, the predefined sets Data, Ports 
and Routes, the special event variable e, and the set where it is supposed to 
range. These are also the events of the LOTOS specification. 

I MODULE AlsNodeInterface 1 

VARIABLE e 

CONSTANTS N, Data, Ports, Routes 

EventSet = 

{(“DATA_IN”, d, r, p) : d G Data, r G Routes, p € Ports} 

U {(“DATA_OUT", d, r, p) : d G Data, r G Routes, p G Ports} 

U {(“DATA_LOSS”, d, r) : d G Data, r G Routes} 

U {(“CTL", p) : p G Ports} 

U {(“CTL", r, p) : r G Routes, p G Ports} 

EventTypeInvariant = e G EventSet U {{)} 



The monolithic TLA-I- specification of Al’s Node is provided in two steps, by 
modules Internal AlsNodeMonol and AlsNodeMonol below. The attribute ’inter- 
nal’ refers to the fact that the specification in that module makes use of vari- 
ables msgBag, activePorts, activeRoutes, that should not be regarded as con- 
tributing to the reference, observable behaviour of the system. Adopting the 
process-algebraic view, the only observable behaviour should be that expressed 
by events, that is, by variable e (which is contributed by module AlsNodeIn- 
terface). Thus, in module AlsNodeMonol all variables except e are hidden, by 
means of temporal existential quantification. 
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MODULE InternalAlsNodeMonol 

EXTENDS AlsNodeInterface , Naturals, Bags 

VARIABLES to be internalized 

msgBag, bag of messages in transit 

activePorts , set of active ports 

activeRoutes the dynamic association ronte-port 

Typeinvariant = 

A EventTypeInvariant 
A Is ABag (msgBag) 

A BagToSet(msgBag) G subset (Data x Routes) 
A activePorts G subset Ports 
A activeRoutes G SUBSET (Routes x Ports) 

Dataln(d, route, port) = 

A e' = (“DATA_IN”, d, route, port) 

A port G activePorts 

A msgBag' = msgBag 0 SetToBag({(d, route)}) 
A UNCHANGED (activePorts , activeRoutes) 

DataOut(d, route, port) = 

A e' = (“DATA_OUT”, d, route, port) 

A port G activePorts 
A (d, route) G BagToSet(msgBag) 

A (route, port) G activeRoutes 
A msgBag' = msgBag 0 SetToBag({(d, route)}) 
A UNCHANGED (activePorts , activeRoutes) 

DataLoss(d, route) = 

A 3 a; G BagToSet(msgBag) : x = (d, route) 

A e' = ( "DATA_LOSS” , d, route) 

A msgBag' = msgBag 0 SetToBag({(d, route)}) 
A UNCHANGED (activePorts , activeRoutes) 

AddPort(port) = 

A e' = (“CTL", port) 

A port ^ activePorts 
A activePorts' = activePorts U {port} 

A UNCHANGED (msgBag, activeRoutes) 

AddRoutePort (route, port) = 

A e' = ("CTL”, route, port) 

A (route, port) ^ activeRoutes 
A activeRoutes' = activeRoutes U {(route, port)} 

A UNCHANGED (msgBag, activePorts) 
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Init 



Next 



Spec 



A e = 0 

A ms g Bag = Empty Bag 
A activePorts = {} 

A activeRoutes = {} 



V 3 (i G Data, r € Routes, p G Ports : Dataln{d, r, p) 

V 3 (i G Data, r G Routes, p G Ports : DataOut{d, r, p) 

V 3 rf G Data, r G Routes : DataLoss{d, r) 

V 3p G Ports : AddPort(p) 

V 3r G Routes, p G Ports : AddRoutePort{r, p) 



A 



Init A □ [Next] ^ 



e, msgBag, activePorts, activeRoutes) 



I 

BagConstraint = B ag Cardinality {ms g Bag) < N 
THEOREM Typeinvariant 

I 



H 



J 



MODULE AlsNodeMonol 

EXTENDS AlsNodeInterface 

Inner {msgBag, activePorts, activeRoutes) = 

INSTANCE InternalAlsNodeMonol 

Spec = 3 msgBag, activePorts, activeRoutes : 

Inner {msgBag, activePorts, activeRoutes)! Spec 



The central part of module InternalAlsNodeMonol consists in the definition 
of five basic actions: Datain, DataOut, DataLoss, AddPort, AddRoutePort. Each 
manipulates in a different way parts of the global state, and accounts at the 
same time for one event type which, in the first three cases, has the same name 
as the action predicate. These five actions appear as disjuncts in the global ac- 
tion Next. Finally, formula Spec defines all legal behaviours of Al’s Node: these 
are infinite sequence of global states in which the first element satisfies the Init 
formula, and any pair of adjacent states satisfies the Next action, or leaves all 
variables unchanged {stuttering step). Note that, although in principle a step 
could simultaneously satisfy more than one basic action, this never happens 
because the actions end up being mutually exclusive, if not for the incompatibil- 
ity of their pre-conditions, because of the disjoint event sets that they support 
(post-conditions) . 

The correspondence between the LOTOS and TLA-I- specifications is clear. 
In particular: LOTOS choice corresponds to disjunction; selection predicates 
and the updated process parameters reflect pre- and post-conditions in TLA-I- 
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Fig. 1. Constraint-composition for Al’s Node 



actions; the LOTOS symbol ’?’ corresponds to existential quantification, which 
generalizes disjunction. 

3 Event-Based, Constraint-Oriented Specification 

In this section we first provide an informal, constraint-oriented description of 
Al’s Node and its LOTOS formalisation, essentially following [QA89]. Then we 
introduce two TLA-I- specifications meant to approximate, in two different ways, 
the compact structure of the LOTOS specification. 

3.1 Informal 

The behaviour of Al’s Node is captured by the three constraints illustrated in 
Figure 1. This diagram reflects the key ideas of event-based, constraint-oriented 
specification. The behaviour of a system is conceived as the composition of some 
constraints, each insisting on some subset of the externally visible events. Typ- 
ically, these subsets are partially overlapped. A constraint C may encapsulate 
data structures; these are not directly accessible by the other constraints. Based 
on their values, C expresses pre-conditions that concur in determining the ’when’ 
(ordering constraints) and the ’what’ (constraints on parameters) of its con- 
trolled events. On other parameters of these events, as well as on the other 
events, C has no influence. An event occurrence has an impact on the data 
structures of all the constraints that support the event (post-conditions) . 
Informally, the constraints for Al’s Node are as follows: 

MsgTransit Messages consisting of a {data, route) pair are input by the system 
and stored. Each of the stored messages is eventually lost or output. 
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ActivePorts Messages can be input and output only at one of the currently 
active ports. The set of currently active ports can be updated, by adding 
one new port at a time. 

ActiveRoutes A {data, route) stored message can be output only at a port 
which is associated, according to the current active routings, to the message’s 
route. The current active routings can be updated, by adding one new {route, 
port) pair at a time. 

The above description contains the same information as the previous, monolithic, 
informal description of the system, but organizes it into three partial behavioural 
views according to a principle of separation of concerns intended to favour both 
the writing and the reading of this type of documentation. 

3.2 Constraint- Oriented Specification in LOTOS 

The three constraints of Al’s Node behaviour are directly expressed, in LOTOS, 
by the following three processes. We use the same constants, predefined sets and 
events of the monolithic specification, and a constant NoMsg, that is required to 
be different from any message. Note that process MsgTransit is in turn defined 
in terms of an auxiliary process OneMsg. Ultimately, MsgTransit is formed by N 
interleaved instances of process OneMsg, each temporarily holding one message, 
or no message. We write msg[l] and msg[2] for denoting the two components of 
a message. 

PROCESS MsgTransit [DATA_IN, DATA_0UT, DATA_L0SS] (k: Nat) 

[] [k > 1] -> OneMsg [DATA_IN, DATA_0UT, DATA_L0SS] (NoMsg, Empty) 

I I I 

MsgTransit [DATA_IN, DATA_0UT, DATA_L0SS] (k-1) 

[] [k = 1] -> OneMsg [DATA_IN, DATA_0UT, DATA_L0SS] (NoMsg, Empty) 

WHERE 

PROCESS OneMsg [DATA_IN, DATA_0UT, DATA_L0SS] 

(msg: Data x Routes, status: {Empty, Full}) 

[] [status = Empty] -> DATA_IN ?d: Data ?r: Routes ?p: Ports; 

LET msg’ = <d, r>, status’ = Full IN OneMsgl ] (msg’, status’) 

[] [status = Full] -> DATA_0UT !msg[l] !msg[2] ?p: Ports; 

LET msg’ = NoMsg, status’ = Empty IN OneMsg[ ] (msg’, status’) 

[] [status = Full] -> DATA_L0SS !msg[l] !msg[2]; 

LET msg’ = NoMsg, status’ = Empty IN OneMsg[ ] (msg’, status’) 

ENDPROC (* OneMsg *) 

ENDPROC (* MsgTransit *) 



PROCESS ActivePortsHandler[DATA_IN, DATA_0UT, CTL] 
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(ActivePorts : SUBSET of Ports) 

[] DATA_IN ?d: Data ?r: Routes ?p: Ports [port in activePorts] 
ActivePortsHandler [ ] ( ) 

[] DATA_0UT ?d: Data ?r: Routes ?p: Ports [port in activePorts] 

ActivePortsHandler [ ] ( ) 

[] CTL ?p: Ports [port in activePorts] 

LET activePorts’ = activePorts \union -[p]- IN 

ActivePortsHandler [ ] (activePorts ’ ) 

ENDPROC (* ActivePortsHandler *) 

PROCESS ActiveRoutesHandler [DATA_IN, DATA_0UT, CTL] 

(ActiveRoutes : SUBSET of (Routes X Ports)) 

[] DATA_0UT ?d: Data ?r: Routes ?p: Ports [<d, r> in ActiveRoutes]; 
ActiveRoutesHandler [ ] ( ) 

[] CTL ?r: Routes ?p: Ports [<r, p> notIn in ActiveRoutes]; 

LET activeRoutes ’ = activeRoutes \rmion -[<r, p>]- IN 

ActiveRoutesHandler [ ] (activePorts ’ ) 

ENDPROC (* ActivePortsHandler *) 

Once the three constraints are defined as processes, their composition is de- 
scribed by a parallel expression, which directly reflects the cooperation pattern 
of Figure 1. This if found in the body of process AlsNodeCO (’CO’ stands for 
constraint-oriented) . 

PROCESS AlsNodeCO [DATA_IN, DATA_0UT, DATA_L0SS, CTL] 

(n: Nat) 

MsgTransit[DATA_IN, DATA_0UT, DATA_L0SS] (n) 

I [DATA_IN, DATA_0UT] I 

(ActivePortsHandler [DATA_IN, DATA_0UT, CTL] (EmptySet) 

I [DATA_0UT] I 

ActiveRoutesHandler [DATA_0UT, CTL] (EmptySet) 

) 

ENDPROC (* AlsNodeCO *) 



3.3 First Constraint-Oriented Specification in TLA-|- 

The challenge we pose now, in moving to state-based specification, and to TLA-P 
in particular, is to try and preserve the three-fold structure of the constraint- 
oriented specification, first by independently describing the three constraints, 
and then by trying to combine them in a compact expression. 

Even more ambitiously, we try to do that by using only what we might call 
’basic TLA-I-’. In the introduction of [7] Lamport indicates that the basic con- 
cepts introduced in Part I of his book should enable the reader to handle most 
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of the specification problems one is likely to encounter in ordinary engineer- 
ing practice. Thus, we stick to those basic concepts and investigate the extent 
to which constraint-oriented specification fits into this picture. An additional, 
pragmatic reason for this restriction is that we want to verify our specifications 
by the TLC tool, which currently does not handle the composite specifications 
discussed in Part II of that book (’More advanced topics’). 

In basic TLA-I- one models a complex component by writing a complex ac- 
tion. The action consists of a disjunction of more elementary actions, each de- 
scribing some event possibility. For writing our constraint-oriented specification 
we use the conventional, write-only, event variable e, and set two requirements: 

— Each constraint must be described by a separate action, handling a disjoint 
portion of the global state, namely the bag of messages, the set of active 
ports, and the set of active routes; these actions must share only the generic 
event variable, and must cooperate in defining its value, according to con- 
straint groupings that depend on the type of event, as illustrated in Figure 1. 

— The global system (action Next) must only refer to those three actions, not 
to their sub-components. 

Composition can only be logical conjuntion or disjunction; disjunction is readily 
excluded - it is too weak - and we are left with the tentative definition: 

Next = MsgTransit A ActivePortsHandler A ActiveRoutesHandler 

The problem now is one of defining the three component actions in such a way 
that the global behaviour is as expected. Since each component is going to be 
a disjunction of sub-components, and some sub-components contain only partial 
descriptions of events, to be conjoined with complementary, partial descriptions 
of the same event in other constraints, we need to make sure that the global 
conjunction induce all the desired pairings among the disjuncts, but only those 
pairings. 

To this purpose, we design our first TLA-I- specification according to the 
following three criteria: 

— We explicitly identify, for each constraint, the subset of events of primary 
interest (called Key Events): these are events that involve the reading and/or 
writing of the state variables the constraint is in charge of. 

— Each constraint C is described as the disjunction of two cases: if the occurring 
global event is one of the key events, then C contributes to it by a disjunction 
of sub-components, say Ci, ..., C„, each one describing a different type or 
subtype of event; if the global event is not a key event, then C contributes by 
’neutrally’ allowing the event to occur (’don’t care’) and by simply making 
sure that its own state variables are unaffected. 

— As required, the sub-components Ci, ..., C„ of constraint C shall only ma- 
nipulate the set, say C^ars, of state variables controlled by the constraint. 
However, if some Ci updates only some of these variables, it will also make 
sure that the other variables of C^ars are unaffected. 
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The need to preserve the value of some variables across a step is a consequence 
of the fact that in TLA-I- the variables not explicitly controlled by an action can 
assume arbitrary values. 

TLA-I- module AlsNodeCOl below directly reflects the requirements and cri- 
teria above. 



MODULE AlsNodeCOl 

EXTENDS AlsNodeInterface, Naturals, FiniteSets, TLC 



VARIABLES 

msg, 

ctl, 

activePorts , 
activeRoutes 



array of N messages in transit 

array of N control states 

set of active ports 

the dynamic association ronte-port 



Typeinvariant = 

A EventTypeInvariant 

A msg € [1 . . A ^ {{Data x Routes) U {()})] 
A ctl G [1 . . A ^ {"empty”, “full”}] 

A activePorts G SUBSET Ports 
A activeRoutes G SUBSET {Routes x Ports) 



I 

EventSubset{key) = {ee G EventSet : ee yf () A ee[l] = key} 

I 

MsgTransit-In = 

3 z G 1 . . A, d G Data, route G Routes, port G Ports : 
A ctl[i] = “empty" 

A ctl' = [ctl EXCEPT ![z] = “full”] 

A e' = (“DATA_IN”, d, route, port) 

A msg' = [msg except ![z] = {d, route)] 



MsgTransit-Out = 

3 z G 1 . . A, d G Data, route G Routes, port G Ports : 
A ctl[i] = “full” 

A msg[i] = (d, route) 

A ctl' = [ctl EXCEPT ![z] = “empty”] 

A e' = (“DATA_OUT”, msg[i][l], msg[i]\2], port) 
A msg' = [msg except ![z] = ()] 



MsgTransit-Loss = 

3 z G 1 . . A, d G Data, route G Routes : 

A ctl[i] = “full” 

A msg[i] = (d, route) 

A ctl' = [ctl EXCEPT ![z] = “empty”] 

A e' = ( “DATA_LOSS” , ms 5 [z][l], msg[i][2]) 
A msg' = [msg except ![z] = ()] 



1 



1 

1 
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MsgTransit = 

LET KeyEvents = 

EventSubset{ "DATA_IN" ) 

U EventSuhset{“£>IKYIKJ^\J'T'') 

U EventSuhset\''DKYIKA.OSS’’) 

IN 

V A e' G KeyEvents 

A V MsgTransit-In 

V MsgTransit-Out 

V MsgTransit-Loss 

V A e' G EventSet \ KeyEvents 

A UNCHANGED {msg, ctl) 

ActivePortsHandler^ControlIn = ... 
ActivePortsHandler^Dataln = ... 
ActivePortsHandler^DataOut = ... 
ActivePortsHandler = ... 



ActiveRoutesHandler-ControlIn = . . . 
ActiveRoutesHandler-DataOut = ... 
ActiveRoutesHandler = ... 



/nzi = 

A e = 0 

A msg = [i G {I . . N) 1 -^ ()] 

A ctl = [i G {I . . N) 1 -^ “empty"] 

A activePorts = {} 

A activeRoutes = {} 

Next = 

A MsgTransit 
A ActivePortsHandler 
A ActiveRoutesHandler 

Spec Init A ^{Next^(^^^ Q^UvePorts^ activeRoutes) 

AlsNodeC02Instance = instance AlsNodeC02 
AlsNodeC02Spec = AlsNodeC02Instance\Spec 



THEOREM Spec OTypeInvariant 
THEOREM Spec => AlsNodeMonol\Spec 
THEOREM Spec AlsNodeC02Spec 
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3.4 Second Constraint- Oriented Specification in TLA-|- 



A second approach to the constraint-oriented specification of Al’s Node in TLA-I- 
is suggested by considering the two-step procedure introduced in [14] for trans- 
forming a LOTOS multiple parallel expression into a set of algebraic expressions 
describing explicitly the process groupings that support the events at the differ- 
ent gates. 

Let us apply the first step of that simple procedure to the top behaviour 
expression of LOTOS process AlsNodeCO. For every gate G we rewrite the 
parallel expression as follows: we replace a process instantiation by the plain 
process name, if G is in the gate list of that process, and by a zero otherwise; 
and we replace a parallel operator by a product operator, if G is in the list of 
synchronization gates, and by a sum operator, if it is not. We thus obtain the 
following set of gate-labelled algebraic expressions: 



DATA_IN: 
DATA_0UT : 
DATA_L0SS : 
CTL: 



MsgTransit * (ActivePortsHandler + 0) 

MsgTransit * (ActivePortsHandler * ActiveRoutesHandler) 
MsgTransit +(0*0) 

0 + (ActivePortsHandler + ActiveRoutesHandler) 



By the second transformation step, these expressions are flattened into SOP 
(sum of products) form: 



DATA_IN: 
DATA_0UT : 
DATA_L0SS : 
CTL: 



MsgTransit * ActivePortsHandler 

MsgTransit * ActivePortsHandler * ActiveRoutesHandler 
MsgTransit 

ActivePortsHandler + ActiveRoutesHandler 



Each gate-labelled SOP represents now the possible groupings of processes that 
support the events at that gate (see [14] for details). 

Module AlsNodeG02 below represents an alternative, constraint-oriented 
specification of Al’s Node in which the global Next action is formed by exactly 
the five disjuncts above (interpreting sum and product as disjunction and con- 
junction, respectively). Each disjunct refers to a specific event type, as identified 
by the different gates. Notice that we could make use of the same elementary 
actions used in module AlsNodeGOl, which is instantiated with name GOl. 



MODULE AlsNodeG02 

EXTENDS AlsNodeInterface, Naturals, FiniteSets 



VARIABLES 

msg, 

ctl, 

activePorts , 
activeRoutes 



array of N messages in transit 

array of N control states 

set of active ports 

the dynamic association route-port 



I 

GOl = INSTANCE AlsNodeGOl 



i 



H 

H 
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Init = COlUnit 

Typeinvariant = CO 11 Typeinvariant 
EventSuhset{x) = C01\EventSuhset{x) 



1 

Msg Transit 


1 

V COW.MsgTransit-In 

V COWMsgTransit-Out 

V COWMsgTransit-Loss 


ActivePortsHandler = 

V COl [ActivePortsHandler^ Controlln 

V COllActivePortsHandler^Dataln 

V COWActivePortsHandler^DataOut 


ActiveRoutesHandler = 

V COW ActiveRoutesHandler _ControlIn 

V COW. ActiveRoutesHandler _DataOut 

1 1 


1 

Next = 

V 


1 

A e' G EventSuhset{“DNTIKAH') 

A MsgTransit 
A ActivePortsHandler 
A UNCHANGED activeRoutes 


V 


A e' G EventSubset{“DNTA_0\JT" ) 
A MsgTransit 
A ActivePortsHandler 
A ActiveRoutesHandler 


V 


A e' G i?ueni5'M&sei( “DATA_LOSS" ) 
A MsgTransit 

A UNCHANGED activePorts 
A UNCHANGED activeRoutes 


V 


A3p G Ports : e' = ("CTL”, p) 
A UNCHANGED (msg, ciZ) 

A ActivePortsHandler 
A UNCHANGED activeRoutes 


V 


A3r G Routes, p G Ports : e' = (“CTL", r, p) 
A UNCHANGED {msg, ctl) 

A UNCHANGED activePorts 
A ActiveRoutesHandler 


Spec Init A ^ dcf^iyePorts., activeRoutes) 

AlsNodeCOlSpec = COllSpec 

1 1 
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THEOREM Spec => □ Typeinvariant 
THEOREM Spec => AlsNodeMonol\Spec 
THEOREM Spec => AlsNodeCOlSpec 



Care should be taken in preventing uncontrolled behaviour of state vari- 
ables that are not explicitly handled by a product of elementary actions. Thus, 
the disjuncts in the body of Next, derived from the SOP’s, are enriched by 
UNCHANGED clauses that handle those excluded variables: in this way, each 
disjunct covers the complete global state. 

4 Verification 

Are the two constraint-oriented TLA-I- specifications correct implementations of 
the more abstract, monolithic specification of Al’s Node? In TLA, implementa- 
tion is implication. Thus, let us start by verifying, using the TLC model checker, 
that the Spec in module AlsNodeCOl implies the Spec in module AlsNodeMonol. 
Recall that the latter is obtained from module InternalAlsNodeMonol by hiding 
all variables except the event variable e. The proof consists then in exhibit- 
ing a refinement mapping that relates the variables of AlsNodeCOl to those of 
InternalAlsNodeMonol. Module MCAlsNodeCOl below (MC stands for ’Model 
Checker’) extends module AlsNodeCOl by adding the definition of the desired 
refinement mapping. 



MODULE MCAlsNodeCOl 

EXTENDS Bags, AlsNodeCOl 

omsqBaq = a state function of (ctl, msq) 

LET f[k e (0 . . N)] = 
w k > 0 

THEN 

IF ctl[k] = "full" 

THEN SetToBag{{msg[k]}) (B f[k — 1] 
ELSE f[k - 1] 

ELSE Empty Bag 
IN f[N] 



AN = INSTANCE InternalAlsNodeMonol with msgBag ^ omsgBag 
ImplementationProperty = ANlSpec 



THEOREM Spec ImplementationProperty 
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The theorem at the end of the module states that if the tuple of variables 
(e, msg, ctl, activePorts, activeRoutes) behaves as specified by the Spec in mod- 
ule AlsNodeCOl, then the tuple (e, omsgBag, activePorts, activeRoutes) behaves 
as specified by the Spec in module Internal AlsN ode, with omsgBag playing the 
role of msg Bag. The refinement mapping provides ’witnesses’ for the hidden vari- 
ables msgBag, activePorts, activeRoutes of the Spec in module AlsNodeMonol; 
in particular, the implementation handles exactly the same data structures ac- 
tivePorts and activeRoutes of the internal, abstract specification, so that the 
refinement mapping for them is just the identity function (see [7] for further 
discussion on refinement mappings, and on the way TLC supports these proofs) . 
The module required for proving that also our second TLA-I- constraint-oriented 
specification implements the initial, monolithic specification, is identical to the 
module above, except that the EXTENDS clause has to refer to AlsNodeC02. 

Although the two constraint-oriented specifications of Al’s Node have been 
developed by following different intuitions, a closer comparison of the definitions 
of MsgTransit, ActiveRoutesHandler, ActivePortsHandler, and Next in the two 
modules suggests that they might be logically equivalent. Rather than manually 
rewriting one into the other, we run again TLC, and prove their equivalence by 
showing that they imply each other (note that they manipulate exactly the same 
state variables). The two relevant theorems appear at the bottom of modules 
AlsNodeCOl and AlsNodeC02. (For convenience of exposition, the two modules 
we show end up instantiating each other; of course TLC cannot handle this 
circularity, and before running the tool, one has to edit them so that they refer 
to each other in turns.) 

5 Conclusions 

We have investigated the possibility to export what we consider an elegant, 
event-based specification style, based on constraint composition, to a state-based 
formalism such as TLA-I-. For doing so, we have introduced in our TLA-I- spec- 
ifications a special purpose, write-only variable, conventionally called e, which 
plays the role of LOTOS gates and events. When composing TLA-I- actions 
by logical conjunction, this variable plays a crucial role in selecting the desired 
pairings of disjuncts, while filtering out the undesired ones. 

The main advantage of using a process-algebraic formalism for writing speci- 
fications in constraint-oriented style is one of conciseness: the ad-hoc specialized 
operator of selective synchrony allows one to capture constraint composition 
by compact parallel composition expressions. Not surprisingly, using the more 
generic, logical conjunction operator generally leads to longer specifications. In 
particular, one has to split the specification effort between two complementary 
concerns: describing the changes of some variables, and making sure that other 
variables preserve their values. This feature, known as the ’frame problem’, is 
shared by other logic-based formalisms, e.g. Z, while is completely absent in 
event-based formalisms. 
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However, moving to a state-based, and logic-based setting, while retaining 
event-oriented thinking, may offer some benefits: 

— The formalism is more basic, more general, and can be learnt more easily. 

— Specifications can be manipulated and transformed by simple and univer- 
sally recognized laws of logics, rather than by specialized algebraic laws for 
behavioural operators. 

— When events are assimilated to state variables, they inherit all the manipula- 
tion techniques available for the latter. For example, one can express different 
levels of visibility, for a given specification, by simultaneously hiding some 
components of the global state and some components of the event. 

This last circumstance enables interesting expressive and analytical possibilities 
that we have only started to explore. 
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Abstract. Software engineering is based today to a large extend on rapid 
prototyping languages or design environments which are high level, very 
expresive, executable and enabling the quick production of running prototypes, 
whereas formal methods emphasices the preciseness and proper mathematical 
foundations which eanhle the production of unambiguous references needed in 
protocol engineering. The goals of formal methods and rapid prototyping are 
not in contradiction, but have very rarely been considered together. This paper 
analyzes the evolution, background and main divergence points, in order to 
highligh how convergence could be achieved. 



1 Introduction 

Mathematical models and techniques are at the core of many engineering disciplines 
and physical sciences. Those mathematical models usually define abstract views or 
properties of systems allowing a better understanding of the main parameters and 
elements. Traditionally, engineering disciplines have made use of mathematical 
models to highlight the relevant parameters of a given design problem, while hiding 
the irrelevant aspects to reduce the complexity of the design process. 

Computer science and engineering differs from most engineering disciplines 
because it focusses in the design of digital systems which are discrete, as opposed to 
the analog nature of the systems addressed by most other engineering disciplines. 
Telecomunnication engineering dealt originally with analog radio or electrical 
signals, but the strong trend in last decades towards unification of information 
representation in digital multimedia formats has transformed most telecomunication 
systems into highly specialised computers for switching or processing some kind of 
multimedia information in digital format. For example telephone exchanges or packet 
routers. Therefore telecom engineering deals today also to a large extend with digital 
systems. 

Digital systems are implemented directly as hardware systems when the 
complexity is low and the higher cost of the design is justified by large productions. 
But most digital system designs are implementated as software. Software based 
systems have usually a huge complexity and therefore research has focussed 
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intensively during the last decades in methods and techniques able to cope with 
complexity. 

Mathematical models of discrete systems have been used since the beginnings of 
computer science. Digital systems are modelled with various types of finite state 
machines, also called automata. But the huge number of states that most systems 
have, makes this model more a conceptual tool than a real engineering tool. Therefore 
automata were extended with standard programming variables to achieve a more 
understandable representation of large state spaces, leading to “extended automata” as 
a more powerfull mathematical model of discrete systems. 

The programs of the first processors were coded directly in the machine language 
of the processor. The reference which defined the semantics of the machine language 
and the programs was the processor itself and there was not a need of a mathematical 
model of the processor for program designers. 

High level languages, such as Fortran, Cobol, Pascal or C, appeared soon and 
provided mathematical abstractions of digital states in the form of variables and of 
program control in the form of high level program instructions. High level languages 
have a much higher expressive power than machine language and allow more 
productive and effective designs of programs. High level language programming is 
based on a set of software tools (compilers, debuggers, etc.) which allow execution of 
high level programs. High level languages have been also applied to the design of 
hardware systems. 

High level languages created the need for new mathematical models, because tools 
for high level programming languages have to be implemented usually in many 
different processors and operating systems. Therefore a precise definition of the 
syntax and semantics of programming languages was needed, as a reference for 
compiler implementation, because all compilers should generate a code executing in 
the same way in each different processor or operating system. 

There exists also a large community of more practmatic computer scientists that 
claim that the most effective way of defining semantics is having reference 
implementations. Reference implementations are implementations which have been 
extensively validated and agreed within a given community or committee to be the 
reference towards which correctness will be determined. Reference implementation 
are usually based on open software to facilitate product generation. 

About two decades ago a big community of researchers and engineers started to 
apply mathematical modelling languages as a means to precisely define the semantics 
and behaviour of complete computer systems or parts of them, because they claimed 
that many problems of existing software or systems were due to the lack of a precise 
mathematical definition of the languages, procedures and tools used. 

This community was especially important in computer networking [8], because 
network protocols are algorithms which have to be implemented in any machine to be 
connected to a network and mathematical models were considered the most precise 
way of specifying the protocols which should form the reference architecture of the 
standardized computer networks which were being designed at that time. 

This community was named the “formal methods” or “formal techniques” 
community and had as it main objective the development of rigurous and precise 
mathematical techniques able to support the development of programs, computers 
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systems, communication protocols, etc. The ultimate goal of this community was the 
development of a complete mathematical formalization of the software and systems 
design process, covering from the initial requirements specification phases to the final 
implementation of the running systems, which assured the correctness by construction 
of the implementation with respect to all the requirements and design decisions 
imposed during the development process. 

To achieve this goal many new elements are needed such as, precise description 
languages, abstraction, stepwise refinement, correctness verification and validation 
techniques, transformation techniques, implementation generation techniques, testing 
tools and theories, etc. All this new developments should have a well defined 
mathematical semantics and should enable a new era of rigorous and fail save 
software and systems design. 

The paper will focuss in the rest on the analysis of the achievements and failures 
and especially in the relation with techniques which have been accepted in industry 
for performing software engineering. The paper focusses also only in the use of 
formal methods in protocol engineering, communication networks and distributed 
applications, although many of the conclusions can be applied to a more general 
context. 

2 Software Engineering and Formal Methods 

Software engineering is the discipline concerned with creating and maintaining 
software applications by applying computer science, project management, domain 
knowledge, and other skills and technologies. Cost-effectivenes, product development 
lead-times, existance of proper design tools or environments and availability of 
trained people are mandatory issues for industry to accept new methods or tools. 

Most protocol implementations are software developments and therefore, formal 
methods research should address industry priorities and should fully integrate into 
software engineering practices to be successfully incorporated. Lets analyze how 
formal methods and software engineering have evolved to try to understand better 
how formal methods research should be incorporated in software engineering 
practices. 

Formal methods based processes rely on the vision that the main characteristics 
and features of a system can be specified in the first phase of the design process and 
that the rest of this design process refines this initial specification introducing design 
decisions which lead at the end of the process to a correct implementation which 
fulfills the initial requirements. 

The design process may consist of more than one step, where each step takes as 
input a given partial definition of the system and generates a more complete 
definition of the system which should be proven correct with respect to the previous 
design steps, by some kind of mathematical correctness proof In networking 
architectures the input specification is usually called the service and the 
implementation of the service is called the protocol. 

This design model is very much in line with the waterfall model proposed in 1970 
by W. Royce [1], which is considered somehow obsolete. It has been considered by 
several authors as the “dream of the western manager” because it would allow 




36 Juan Quemada 



managers to precisely specify their objectives, strategies and requirements, which the 
rest of the organisation should just implement. Such a model would provide the 
project manager with an absolute amd rigorous control of the developments made. 

During all those years of intensive research in formal methods, the software 
engineering community and industry has evolved and developed different approaches 
which have proven very effective, such as rapid prototyping, the spiral model, 
extreme programming, agile methods, etc [2, 3, 4], which have been widely accepted 
by industry. 

Those methods are based on the vision that the main features of a complex system 
can not be properly understood in the first phases of the design process. Designers 
know at the beginning only the problem they have to solve. 

The design process should be therefore an incremental learning and design process 
based on rapid prototyping. Early prototypes must be produced of the least 
understood parts, to gain a better understanding, as well as to obtain early 
user/customer feedback and allow testing. 

As the “Manifesto for Agile Software Development” [3] states, the emphasis is 
put, in those approaches, much more on frequent software prototypes, adaptation to 
changes and direct interaction/collaboration among designers and/or customers, than 
on requiremments, planning or documentation. 

In prototyping based software engineering approaches the emphasis is put on rapid 
prototyping languages or design environments which are high level, very expresive 
and executable, enabling the quick production of running prototypes, rather than in 
preciseness or proper mathematical foundations as formal methods emphasice. 

The goals of formal methods and of rapid prototyping are not in contradiction, but 
have very rarely been considered together. The formal methods community should 
probably take into account the main trends of software engineering and try to provide 
solutions for the problems that software engineering has, rather than trying to develop 
a complete independent design framework. 

2.1 Dealing with Complexity and Rensability of Software 

Management of complexity has been one of the main challenges in software 
engineering. Abstraction is the main conceptual tool for dealing with complexity and 
most programming and specification languages include abstraction mechanisms such 
as, procedures as abstractions of operations, variables/records/structures as 
abstractions of state, objects as abstractions of program modules with clear usage 
interfaces, processes as abstractions of behaviour, etc. 

There exist a large consensus that the object oriented model is the right abstraction 
mechanism in sequential programming languages, for building well structured 
programs, as well as reusable libraries of software components. On the process side 
there is not such a consensus and several models exist especially for interprocess 
communication. 

Todays design and programming languages, as well as, software engineering tools 
have evolved to support the needs of both, software engineering practices and 
mangement of complexity. Nevertheless, the abstraction mechanisms supported in 
programing languages provide only syntactic support for the abstraction mechanisms. 
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Formal methods should have provided semantie support for abstraetions and have 
produeed interesting results in this direetion, but the languages and meehanisms used 
do not fulfill the software engineering needs. 

Providing support for semantie abstraetion in a framework whieh is applieable in 
todays software engineering praetiees is one of the still unrealized main promises of 
formal methods. 



3 Protocol Engineering and FDT Standards 
(Formal Description Techniques) 

The advent of eomputer networking led to the proposal of protoeol engineering as 
somehow different form software engineering [5, 6, 7, 8]. Protoeol engineering 
eonsidered the following vision and goals, espeeially within the eommunity whieh 
eonsidered that the use of formal methods was the only way of ereating a rigorous 
engineering diseipline. 

• Protoeol standards should be legal or defaeto standards whieh provide an 
unambiguous referenee for deriving implementations, as well as eonformanee 
test whieh eould assess in praetiee the eorreetness of implementations with 
respeet to the protoeol standard. 

• Protoeols standards should be eorreet. As eorreetness ean only be determined 
with respeet to a given set of requirements, the serviee definition was eonsidred 
the requirements to be met by a given protoeol. 

This vision and goals led to some speeifie ehallenges whieh have guided 
researehers in the formal protoeol engineering eommunity during the last two 
deeades, sueh as 

• Challenge 1. Development of a language for unambiguosly representing 
protoeol standards: To aehieve this ehallenge FTDs (Formal Deseription 
Teehniques) should be developed and standardized to provide a unambigous 
means for deseribing protoeol standards. 

• Challenge 2. Protoeol representations should be proven eorreet: To aehieve this 
ehallenge eaeh protoeol should be aeeompanied by a serviee speeifieation and 
a proof that states that the protoeol is a eorreet implementation of the serviee. 
As there are some properties about eorreetness, sueh as deadloek or starvation 
absenee, whieh are independent of the serviee speeifieation an additional 
validation of sueh properties was required. 

• Challenge 3. Protoeols should also provide the best performanee: To aehieve 
this ehallenge automatie derivation of analytie or simulation models should be 
possible where protoeol performanee eould be anlyzed and optimized. 

• Challenge 4. Protoeol representations should allow automatie derivation of 
eorreet protoeol imlementations: To aehieve this ehallenge automatie derivation 
of implementations using eorreetness preserving transformations were needed. 

• Challenge 5. There should exist a proeedure to verify or validate the 
eorreetness of protoeol implementations: This proeedure was assumed to be 
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based in conformance testing of implementations under test. To achieve this 
challenge automatic test suite derivation from the protocol description should 
be possible with sufficient coverage of the protocol behaviour and state space. 

The first formal description technique was IBMs FAPL [5] which was used to 
deploy early IBM network architectures to a wide range of system, soon followed by 
other proposals. The advantages of having standardized FDT became clear soon. The 
first standardized FDT (or semi, becuase it was not fully formal at the beginning) was 
CCITTs SDL [6] which is based on an extended finite state machine model. SDL has 
been also the most successfull standardized FDT due to it's use for defining several 
CCITT/ITU standards, although the core of the software industry has not adapted it. 
The definition of the ISO-OSI reference model during the eighties and nineties led to 
the definition of two additional FDTs, which where competing with each other and 
with SDL as well. The first one was Estelle [6], which was based on an extended 
finite state machine model and standard Pascal data types. The second one was 
LOTOS [6], which was based on an algebraic calculus of processes and algebraic 
data types. 

There were therefore 2 FDTs (SDL, ESTELLE) based on the less abstract 
“extended automata” model and one FDT (LOTOS) based on the more abstract 
mathematical theories of algebraic calculi of processes and algebraic data types. SDL 
and Estelle are much like programming languages and have more or less the same 
level of abstraction than C, Pascal, ADA or Java, although they were better suited for 
protocol representation. LOTOS on the other hand is more abstract, but it's main 
drawback for application in software engineering is the ACT ONE data definition 
language which has an algebraic semantics and is not executable. The behaviour part, 
based on a mixture of CCS [9] and CSP [10], was extremely powerfull and provided 
solutions for dealing with semantic abstraction which do not exist in todays design 
languages and tools. But the lack of executability of the data part made LOTOS 
difficult to apply. 

Although protocols and network architectures have some minor distinguishing 
features with respect to other software developments, the mayority of the elements of 
the discipline are comon to software engineering and in my opinion, it would have 
been wiser to consider protocol engineering as a specialization of software 
engineering which inherits all it's elements and procedures. The design of the Internet 
was done following many of the software engineering principles explained before and 
its success was probably due to the higher effectiveness of rapid prototyping 
approach as compared to the more waterfall oriented approaches based on formal 
methods, which were used by standards organisations (ISO, CCITT/ITU) and the 
formal methods community. 



4 Protocol Engineering and the Internet 

The success of the Internet was due to many factors. The most important factor was 
probably the early availability of running implementations of the TCP/IP stack, as 
well as the availability of a large variety of applications. When ISO was starting 
work on developing FDTs, the Internet was already operational. Nevertheless, the 
development and of course the success of the Internet would not have been possible 
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if the designers would not have provided effective solutions to the challenges of 
protocol engineering. The protocol engineering behind the Internet was not based in 
formal methods, but provided quite effective solutions which could align in many 
cases even with the agile software development manifesto. 

The working procedures of the IETF, the Internet Engineering Task Force, where 
all Interent standards are produced since it was created in 1886, are close to the 
sofware engineering practices based on rapid prototyping described before. The 
working procedures of the IETF are also much more democratic than those of most 
standard organisations and have had a big impact in the way technology is produced 
today. The effectiveness of the procedures used for developing protocols and 
applications in the IETF led to the early availability of many mnning services, which 
had been properly tunned and adapted to users needs, even if many of the 
components used where not properly optimized. Lead times were more important 
than quality of the result. 

The IETF promoted from the beginning the open participation of researchers into 
standardization committees, where participants could attend on a personal basis 
without any accreditation or fee as it is usually necessary in official standard bodies. 
IETF has also not avoided the existance of competing standards proposals, accepting 
only the proposals which were widely accepted by the user community. A standard 
was never accepted without two or more running implementations. Those 
implementations were used as references and were usually open software which could 
be used in the implementation of the standards on other machines. Those practices 
motivated a large community of researchers and developers to contribute to the 
production of the IETF standards. 

The Internet designers dealt as follows with the challenges of protocol engineering 

• Challenge 1. Development of a language for unambiguosly representing 
protocol standards: IETF standards are described as informal textual 
descriptions to facilitate the understandability. The use of ASCII text has been 
promoted to facilitate editing. Nevertheless, textual description of standards are 
complemented by reference implementations in C, Java, PERL, ..., which are 
the real references with which implementations must interwork. 

• Challenge 2. Protocol representations should be proven correct: Correctness 
was substituted by rapid prototyping and user evaluation. Proposed standards 
had to have several running implementations interworking among them. User 
acceptance substituted proofs of correctness. This makes a lot of sense, because 
a correctness proof of a protocol implementation with respect to a service does 
not mean anything. The important issue is to have services which are accepted 
and usefull for users. 

• Challenge 3. Protocols should also provide the best performance: Protocols 
were optimized using standard simulation techniques. Running prototypes 
provided also a lot of early feedback to improve the performance problems of 
the first versions of the standards. 

• Challenge 4. Protocol representations should allow automatic derivation of 
correct protocol imlementations: Reference implementations did provide an 
effective way of deriving implementations, because most of them are based in 
open software. They were ported and easily recompiled in new machines. 
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Reference implementations were written in high level languages for which 
compilers existed in most machines such as C, Java, PERL, etc. Only the small 
part of the code which was hardware or O.S. dependant had to be rewritten. 

• Challenge 5. There should exist a procedure to verify or validate the 
correctness of protocol implementations: Interworking of implementations 
substituted conformance testing. As most implementation were derived from 
the same reference implementation interworking was not difficult to achieve. 

The solutions given to the challenges of protocol engineering were not very 
innovative, but were cost effective and ready to apply. Therefore innovation focussed 
in providing new services, new networking technologies or improved versions of the 
protocols. Most services were not optimized, but were providing a nice service, were 
running and were ready to deploy. 

On the other hand, in the development of the ISO-OSI reference model and in 
CCITT/ITU FDTs were defined from scratch and as no agreement could be reached 
there were three FDTs competing. No tools were available at the beginning and a lot 
of time and research effort was necesary to have the first prototypes of the compilers 
and design environments ready. The first implementations of the protocols had to be 
therefore handcoded. In addition the ISO-OSI protocol stack had a lower performance 
than the Internet stack due to the fact that the protocols were first specified and then 
implemented. The design life-cycle was very in line with the waterfall model and did 
not assure a proper and well tunned result in time. When this was detected it was too 
late to produce a better version of the OSI protocols. There were many other causes 
for this delay, especially of political nature, but the use of a different methodological 
approach would have led very likely to a better technical result. The Internet had 
started deployment and as it was the only widely available working solution, it was 
adopted by industry despite of the big political support in favour of OSI. 



5 Opportunities and Challenges for Formal Methods Today 

Research in formal methods has not taken into account software engineering practices 
and methodologies as used in industry and therefore the results obtained are difficult 
to apply in real software developments. Software engineering practices need several 
features as mandatory, such as 

• Support for rapid prototyping. The development of early prototypes plays a 
crucial role in todays systems design because it enables an early user or 
customer evaluation, which verification, validation or formal proof systems can 
not support by any means. Early prototyping allows to validate the usability, 
functionality or friendliness and enables early tuning or redisgn. Effective rapid 
prototyping languages must be executable and be very expressive: 

o Executability. Non executable mathematical modelling languages do not 
seem to have applicability in todays software engineering because they do 
not allow prototyping. 

o Being high level. Design languages must allow prototype development with a 
minimum effort and should have therefore powerfull instructions which 
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allow prototype implementation with a minimum number of instructions or 
statements. 

• Support reusability of classes and objects. Design languages must facilitate 
reusability. As object oriented languages are considered as the ones which 
provide the best support for reusability, formal design languages should 
support object orientation. 

• Support for reusability of behaviour definitions. The behaviour or process part 
of the existing design languages needs probably still substantial research, 
because no consensus exist about the best formalism. Algebraic calculi of 
process theory has provided executable process models with very high 
expressive power and nice abstraction features, although integration into 
conventional design languages should be done. 

• Support for semantic abstractions. Design languages for complex systems need 
to have some kind of semantic abstractions which allow to decompose the 
design process into a sequence of understandable steps. Most design languages 
provide some support, but without providing a formal semantics, where 
abstraction mechanisms just perform syntax matching of interfaces. This is 
probably one of the places where formal methods can provide better design 
methods. For example the hiding operation of CCS [9] and LOTOS [6] is a 
very powerfull abstraction mechanism. The testing or conformance relations 
[11, 12] of CCS and LOTOS are formal notions of implementation which can 
be integrated quite smothly into software engineering practices. 

Protocol implementations are like other hardware or software implementations and 
therefore protocol engineering should fully align with software engineering practices. 
The need for a more formal approach to systems and application design still exists, 
but must not ignore all the pragmatic lessons learned in large software developments 
in industry. 

Formal methods researchers should try to develop design languages with support 
for rapid prototyping, with a high expresive power and also with support for semantic 
abstractions for classes and behaviours. This would allow a much smoother design 
process by stepwise refinement where, instead of having the usual sequence of non 
executable formal descriptions, a sequence of executable prototypes would be 
generated, where each prototype can be proven as a correct implementation of the 
previous one, but which can also be evaluated and validated by users/customers. 

The LOTOS formal description technique [6] got very near to this approach at the 
behaviour part, providing semantic abstraction mechanisms which do not exist in the 
design languages used today in software engineering. But the algebraic data part 
made it unusable for software engineering. A language based on the LOTOS 
behaviour part and a conventional executable data typing would have been a very 
powerfull design language at that time. Some industrial trials performed in the 
nineties validated this approach [13]. It was a pitty that this opportunity was missed. 

An expressive and executable language providing formal support to design by 
stepwise refinement can enhance todays state of the art. This language should 
incorporate all the features which today are mandatory in software engineering such 
as, object orientation or module and interface constructs, and of course should 
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support semantic abstractions for objects and behaviour in a way which can be easily 
mapped in todays engineering practices. 

There exist opportunities for using formal methods research results to enrich 
existing design languages and methodologies. For example: The new Web 
architectural framework with all the new XML based languages and tools; or to 
enhance well accepted design languages such as Java of C#. 
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Abstract. Distributed Java applications use remote method invocation 
as a communication means between distributed objects. The ProActive 
library provides high level primitives and strong semantic guarantees for 
programming Java applications with distributed, mobile, secured com- 
ponents. We present a method for building finite, parameterized models 
capturing the behavioural semantics of ProActive objects. Our models 
are symbolic networks of labelled transition systems, whose labels repre- 
sent (abstractions of) remote method calls. In contrast to the usual finite 
models, they encode naturally and finitely a large class of distributed 
object-oriented applications. Their finite instantiations can be used in 
classical model-checkers and equivalence-checkers for checking temporal 
logic properties in a compositional manner. We are building a software 
tool set for the analysis of ProActive applications using these methods. 



1 Introduction 

We aim at developing methods for the analysis and verification of behavioural 
properties of distributed applications, that would be applicable in automatic 
tools, on a real language. At the heart of such tools lie sophisticated static 
analysis techniques, and abstraction principles, that enable the generation of 
finitary models of the behaviour from the source code of the application. A good 
candidate as a behavioural model would be a process algebra with at least value- 
passing features, or even encoding dynamic process and channel creation and 
reconfiguration. Still, despite the very important development in the last 20 
years of value-passing and high-order process theories, most of them are just too 
expressive to be subject to decision procedures, and would not give us models 
and algorithms usable in practical tools. 

At the same time, a number of analysis tools, model-checkers, equivalence 
checkers have been developed, using input formats, in their respective areas; 
that have some of the desired features for our work. For example the Promela 
language, input of the SPIN model-checker, can describe value-passing processes 
and channels with data values of simple types or the NTIF format [1] that en- 
codes the sophisticated communication between E-LOTOS processes. However, 
few of them include compositional structures that would allow to take advantage 
of the congruence properties of process algebra models. Outside the value-passing 
area, it is worth citing the seminal work by Arnold [2], and the MFC language 
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and analysis tool, that permits a direct and finite representation of the synchro- 
nisation constraint between processes. 

Our approach aims at combining the value-passing and the synchronisation 
product approaches. We define a model featuring parameterized processes, value- 
passing communication, behaviours expressed as symbolic labelled transition sys- 
tems, and data- values of simple countable types. We have developed a graphical 
language close to this model, that is powerful and natural enough to serve as 
a specification language for distributed applications [3] . We argue that the same 
model is adequate as the target for automatic model generation for distributed 
applications. As an illustration of the approach, we define the generation proce- 
dure [4] for the Java/ProActive framework. One key feature is that the design 
of the model ensures that it can be automatically and finitely produced from an 
’’abstract” version of the application code, in which data have been abstracted 
to simple types. Then, given a finite instantiation of the variables in the model, 
we have an automatic procedure producing a (hierarchical) finite instantiation 
of the model, suitable for use e.g. in a standard model-checker. 

Our method can be applied in the following way: starting with the source 
code of a real application, the developer would specify an abstraction of its 
data-types, and transform his code accordingly. The work in the Bandera tool 
set [5] shows how this step can be largely assisted by the tool. At this level, 
the design of the abstraction can be tuned specifically to the properties one 
wishes to verify, in order to reduce the size of the generated models. From this 
abstract code, static analysis techniques, plus our model generation procedure, 
produces automatically a parameterized network. Then the developer, for each 
property he wants to prove, will produce a finite network, using a notion of 
instantiation that is again an abstract interpretation in the style of [6], before 
checking the property (or its corresponding instantiation) with a model-checker. 
The instantiation could even be performed on-the-fly, if the checker offers this 
possibility. The properties can be themselves specified as parameterized scenarios 
in our graphical language, or as parameterized formulas in a temporal logics. 

In section 2, we define parameterized labelled transition systems and syn- 
chronisation networks, their instantiations to pure LTS and networks, and the 
corresponding synchronisation product. Then we sketch a generic way of defin- 
ing finite instantiations as abstract interpretations of the parameterized models. 
In section 3, we specialise this model for representing the behaviours of Java 
distributed applications built using the ProActive framework, and give an algo- 
rithm for computing the models from static analysis of the code. In section 4, we 
give an example of model generated for a small ProActive application. Finally, 
we conclude about our work and future research directions. 



2 Parameterized Models 

We give the behavioural semantics of programs in terms of labelled transition 
systems. We specify the composition of LTSs by synchronisation networks [2], 
and give their semantics in term of a synchronisation product. 
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2.1 Theoretical Model 

We start with an unspecified set of communications Actions Act, that will be 
refined later. 

We model the behaviour of a process as a Labelled Transition System (LTS) 
in a classical way [7]. The LTS transitions encode the actions that a process can 
perform in a given state. 

Definition 1 LTS. A labelled transition system is a tuple (S, sq, L, —^) where S 
is the set of states, sq G S is the initial state, L C Act is the set of labels, —>■ is 
the set of transitions: S x L x S . We write s s' for (s, a, s') € 

Then we define Nets in a form inspired by [2], that are used to synchronise 
a finite number of processes. A Net is a form of generalised parallel operator, 
and each of its arguments are typed by a Sort that is the set of its possible 
observable actions. 

Definition 2 Sort. A Sort is a set I C Act of actions. 

A LTS {S, So, L, — >) can be used as an argument in a Net only if it agrees with 
the corresponding Sort {L C Ifj. In this respect, a Sort characterises a family of 
LTSs which satisfy this inclusion condition. 

Nets describe dynamic configurations of processes, in which the possible syn- 
chronisations change with the state of the Net. They are Transducers, in a sense 
similar to the open Lotos expressions of [8] . They are encoded as LTSs which la- 
bels are synchronisation vectors, each describing one particular synchronisation 
of the process actions: 

Definition 3 Net. A Net is a tuple < Ac,I,T > where Aq is a set of global 
actions, I is a finite set of Sorts I = o,nd T (the transducer) is a LTS 

(Tt, sot , Lt, ^t), such that Vlf G Lt, v =< lt,a\, . . . ,an > where It G Aq and 
Vi S [1, n],ai G liU {idle}. 

We say that a Net is static when its transducer vector contains only one state. 
Note that a synchronisation vector can define a synchronisation between one, two 
or more actions from different arguments of the Net. When the synchronisation 
vector involves only one argument, its action can occur freely. 

The semantics of the Net construct is given by the synchronisation product: 

Definition 4 Synchronisation Product. Given a set of LTS {LTSi = 
)Si , , Lt, } i—i...n and a Net ^ Aq , {L . .n ; ? -h'j' , ^7^ ) ^ , such 

that Vi G [l,n],Li C It, we construct the product LTS (S, sq, L, — >) where 
S = St X nr=i(‘^*)' ^ nr=i('^0i); L = Aq, and the transition relation 

is defined as: 

^ {s s'\ s =< St, Si,...,Sn >, s' =< s't, sfy . . . , s'^ > , 

3 St s't G^t,^ =< k,oti, ■ • ■ , cCn >, Vi e [l,n], (ot fy idle A st s' G^t 

) V (at = idle A st = s'f) 



46 



Tomas Barros et al. 



Note that the result of the product is a LTS, which in turn can be synchro- 
nised with other LTSs in a Net. This property enables us to have different levels 
of synchronisations, i.e. a hierarchical definition for a system. 

Next, we introduce our parameterized systems which are an extension from 
the above definitions to include parameters. These definitions are connected to 
the semantics of Symbolic Transition Graph with Assignment (STGA) [9]. 

Parameterized Actions have a rich structure, for they take care of value 
passing in the communication actions, of assignment of state variables, and of 
process parameters. In order to be able to define variable instantiation as an 
abstraction of the data domains (in the style of [6]), we restrict these domains 
to be simple (countable) types, namely: booleans, enumerated sets, integers 
or intervals over integers and finite records, arrays of simple types. 

Definition 5 Parameterized Actions are: r the non-observable action, Ai 
encoding an observable local sequential program (with assignment of variables), 
7m{P,x) encoding the reception of a call to the method m from the process P (x 
will be affected by the arguments of the call) and IP.mfe) encoding a call to the 
method m of a remote process P with arguments e. 

A parameterized LTS is a LTS with parameterized actions, with a set of pa- 
rameters (defining a family of similar LTSs) and variables attached to each state. 
Parameters and variables types are simple. Additionally, the transitions can be 
guarded and have a resulting expression which assigns the variables associated 
to the target state: 

Definition 6 pLTS. A parameterized labelled transition system is a tuple 
pLTS = {K, S, So, L, — >) where: 

K = {ki} is a finite set of parameters, 

S is the set of states, and each state s € S is associated with a finite set of 
variables Vs, 

Sfj £ S is the initial state, 

L = {b,a{fx),~e) is the set of labels (parameterized actions), where b is 
a boolean expression, a{lc) is a parameterized action, and ~e is a finite set of 
expressions. 

C S X L X S is the set of transitions: 

Definition 7 Parameterized Sort. A Parameterized Sort is a set pi of pa- 
rameterized actions. 

Definition 8 A pNet is a tuple < pAq, H,T > where : pAa is the set of global 
parameterized actions, H = {ph, Ki}i-i,,n is a finite set of holes (arguments). 
The transducer T is a pLTS {Kq, St, sq.j., such that\/v G Lt, v =< 

lt,a\^ , . . . > where It G pAc , Oi G pit U {idle} and ki G Ki. 

The Kg of the transducer is the set of global parameters of the pNet. Each 
hole in the pNet has a sort constraint pf and a parameter set Ki, expressing that 
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this ” parameterized hole” corresponds to as many actual arguments as necessary 
in a given instantiation. In a synchronisation vector =< , . . . >, 

each corresponds to the action of the fc^-nth corresponding argument LTS. 

In the framework of this paper, we do not want to give a more precise def- 
inition of the language of parameterized actions, and we shall not try to give 
a direct definition of the synchronisation product of pNets/pLTSs. Instead, we 
shall instantiate separately a pNet and its argument pLTSs (abstracting the do- 
mains of their parameters and variables to finite domains, before instantiating for 
all possible values of those abstract domains), then use the non-parameterized 
synchronisation product (Definition 4). This is known as the early approach to 
value-passing systems [7, 10]. 

2.2 Graphical Language 

We provide a graphical syntax for representing static Parameterized Networks, 
that is a compromise between expressiveness and user-friendliness. We use 
a graphical syntax similar to the Autograph editor [11], augmented by elements 
for parameters and variables : a pLTS is drawn as a set of circles representing 
states and edges representing transitions, where the states are labelled with their 
set of variables (vl) and the edges are labelled by [6] a{lic) ~e (see Defini- 
tion 6). 

An static pNet is represented by a set of boxes, each one encoding a particular 
Sort of the pNet. These boxes can be filled with a pLTS satisfying the Sort 
inclusion condition. Each box has ports on the border, represented by bullets, 
each one encoding a particular parameterized action of the Sort. 

Fig. 1 shows an example of such a parameterized system. It is a simple 
consumer-producer system with a single buffer and an arbitrary number of con- 
sumers and producers. In Fig. 1, the right-most link is a communication name 
Q_put from process Producer(p) to the buffer B, carrying a value x:int that 
the developer has chosen to observe as the event PUT(p,x). 
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The edges between ports in Figure 1 are called links. Links express syn- 
chronisation between internal boxes or to external processes. Each link encodes 
a transition in the Transducer LTS of the pNet. 

The sequential code encoding the control and data-flow 
within a process is carried by macro-transitions, with multi- 
ple output states. We restrict them to sequential programs 
without communication events. This way, we avoid dupli- 
cating code in sequential transitions and at the same time 
avoid the extra interleaving that would be created by macro- 
transitions containing visible events. 

We have used this language extensively in [3] to specify and verify a large 
distributed system from a realistic case study. 

2.3 Instantiations as Abstractions 

From a parameterized network, we want to construct abstract models, with 
parameters in abstract domains simpler than the original (concrete) domains. 
Ultimately the parameter domains should be finite, allowing us to use standard 
model-checking tools on the abstract model. And we want this abstraction to be 
consistent, in the sense that some families of properties (typically reachability) 
are preserved by the abstraction. Thus from the reachability of some abstract 
event in the abstract domain, we can conclude to the reachability of some con- 
crete representative of this event in the original model. 

In a slightly different settings, [6] have shown how to define abstractions on 
value domains, in such a way that they induce safe abstractions on value-passing 
processes (preserving safety and liveness properties). We shall use a similar con- 
struction to define instantiations as safe abstractions of our simple data types: 
an instantiation is a partition (a total subjection) from a simple data type onto 
an abstract domain; lifting the instantiation to sets of values yields a Galois 
connection. 




* 



if x=0 then 
goto s1 ; 
else ... 




3 Application: Models for Distributed Active Objects 

We now specialise our parameterized models, for representing the behaviour of 
distributed applications. We choose a specific framework providing high-level 
distribution and communication primitives for distributed objects, namely the 
ProActive library. ProActive is also endowed with a formal semantics, and the 
library services provide strong guarantees on the communication mechanism, 
that helps a lot in defining our model generation method. 

It should be clear that our parameterized models could also be used for other 
languages or other frameworks. However, providing a similar work for languages 
with weaker semantical properties (like Java with standard RMI, or C with basic 
sockets) would definitely be more difficult, and the various properties of our 
approach (finiteness, abstraction, compositionality) would not be guaranteed. 
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3.1 Java and ProActive 

ProActive [12] is a pure Java implementation of distributed active objects with 
asynchronous remote method calls and replies by means of future references. 
A distributed application built using ProActive is composed of a quantity of 
active objects (or activities), each one having a distinguished entry point, the 
root, accessible from anywhere. All the other members of an active object (they 
are called passive objects) can not be referenced directly from outside. Each 
active object owns its own and unique thread of control and the programmer 
decides the order to serve (or not) incoming calls to its methods. Each active 
object has a pending queue where are dropped the incoming requests to be 
served by the control thread. The requests are done via a rendez-vous phase so 
there is a guaranty of delivery and a conservation of the order of incoming calls. 
The responses (when relevant) are always asynchronous with replies by means 
of future references; their synchronisation is done by a mechanism of wait-by- 
necessity. 

ProActive provides primitives to dynamically create and migrate active ob- 
jects. Dynamic creation is naturally represented in our parameterized models. 
Migration is not treated in this work: the semantics of ProActive ensures trans- 
parent active object migration and remote creation. 

3.2 Data Abstraction 

The aim in this work is to generate parameterized models encoding the be- 
haviour of ProActive distributed objects. The events that we want to observe in 
these models are naturally the communication between activities, plus eventually 
specific local events that the user will specify. 

Being interested in automatic procedure for generating finitely representa- 
tions of the behaviours, and working with a real language, we have a prob- 
lem with the representation of potentially infinite data objects (including user- 
defined classes). So we require that the source code be first transformed by 
abstraction of the data- types of the application into the ’’simple types” of our 
model. 

This transformation cannot be fully automatic, and it will require some in- 
put from the user to specify the abstraction of all types in the code (Fig. 2). 
Furthermore, it will be interesting at this step to abstract away from any data 
information that would not be significant for the properties that the user wants 
to prove. It has been shown, e.g. in the Bandera tool [.5], how such data ab- 
straction can be implemented as code transformation, either at source code or 
intermediate code level. 



3.3 Code Analysis 

The generation of our behavioural models from the source code requires sophis- 
ticated analysis, starting with usual static analysis functions. Class analysis de- 
termines the possible class(es) of each variable in the program, and the possible 
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Fig. 2. Building models of distributed active objects 



identiti(es) of the method called at each invocation point. Then we use Control 
Flow analysis to compute the Method Call Graph, and Data Flow analysis to 
track the values of parameters. The adaptation of these methods to ProActive 
code are not trivial, in particular because the proxy mechanism of the library 
include a lot of dynamic code generation, and we must emulate its effects during 
static analysis. 

Language restrictions : For the sake of this paper, we shall not consider the treat- 
ment of exceptions and arrays. Other aspects, such as Java concurrency features 
(threads, monitors), reflection and dynamic class loading, will not be allowed. 
These features are important indeed in the implementation of the library, but 
are not needed for the library user. 

The rest of this section describes the steps of the model construction. Start- 
ing from the Abstract ProActive code, we build a (static and finite) network 
description, an extended Method Call Graph (XMCG) for each active object 
class, a local pNet for each activity, and finally a pLTS for each method. 

3.4 Step 1: Topology and Communication, Extraction 
of the Global Network 

Static Topology: In general the topology of a distributed ProActive application is 
dynamic and unbounded, because active objects can be created dynamically. We 
compute a static approximation of this topology, in the form of a parameterized 
network based on : the (finite) set of active object classes, the (finite) set of 
active object creation points, and the (finite) set of program points where an 
active object emits a remote request. 

Boxes: Given a set of active object classes, a set of creation points, we obtain 
a set of (parameterized) active objects {Oi}. For each active object creation 
point, we build a Box B{Oi{params)) . 
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Fig. 3. Communication between two activities 



Communication Protocol: Fig. 3 illustrates the communication corresponding 
to a request addressed to a remote activity, its processing and the return of its 
result. A method call to a remote activity goes through a proxy, that locally 
creates a ’’future” object, while the request goes to the remote request queue. 
The request arguments include the references to the caller and callee objects, 
but also to the future. It also contains a deep copy of the method’s arguments, 
because there is no sharing between remote activities. Later, the request may 
eventually be served, and its result value will be sent back and used to update 
the future value. 

Building the Communication Links: In the following we denote m a message 
containing: the (fully qualified) method name, references to the caller, future, 
callee (parameterized) objects, and either the parameters or the return value of 
the message. 

For each active object class, we analyse the relevant source code to compute 
its ports and the corresponding links : 

1. The set of public methods of the active object main class gives us the set 
of ’’receive request” ports IQjm of its box, and their response ports (when 
applicable) \o.Rjm. 

2. We then identify in the code the variables carrying ’’active objects” values, 
using data flow analysis techniques, and taking into account their creation 
parameters. 

3. For each call to a method of a remote object, we add a ’’send request” port 
\o.Qjm to the current box, linked to the corresponding port of the remote 
object box, and if this method expects a result, a ’’response” port IRjnn. 

4. For each local event that we want to observe (e.g. some local method call), 
we add a ’’local” port Calljm to the current box. 

5. For each pair of opposite actions such as IQjm - lo.Qjm, we build a link (in 
this case labelled Qjm). 

Fig. 4 gives an example of such a pNet, computed from the ProActive code 
presented in section 4. 
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Fig. 4. Producers/Consumers: global network 



3.5 Step 2: extended Call Graphs 



For each active object class, we define an extended Method Call Graph (XMCG) 
structure containing the results of usual class and control flow analysis (on all 
classes used by this activity), sequential code encoding the data-fiow, and spe- 
cific constructs relative to the ProActive features namely: active objects, future 
objects, remote requests and responses, mechanism for the selection of requests 
in a request queue. 

An Extended Method Call Graph is a tuple: /m, mo,P, 



where M is a set of fully qualified methods names, mo € M is the initial method 
name, P is a set of nodes, and the two transition relations are respectively the 
inter-procedural (method calls) and intra-procedural (sequential control) trans- 
fer relations. 



The nodes in V are typed as: 



— ent (c, m, args) the entry node of method m G M, called by object c, 

— call {calls) encoding method calls (local or remote), 

— pp {lab) encoding an arbitrary program point with label lab, 

— ret {val) encoding the return node of a method with result value val, 

— serve {calls, mset,pred, mode) encoding the selection of the request m G 
mset from the local request queue, 

— use {fut, val) encoding the point of utilisation of a future value. 



All nodes have at most one outgoing transfer edge < succs{n) = MT, N >, 
with < n, MT, N > G jn which the meta-transition MT is a sequential 

program with a non-empty set of resulting states N . 

Call and Serve nodes have a set of nondeterministic outgoing method call 
edges, calls{n), with Vc in calls{n),3n' . < n, c,n' > € — each call being 

either: 



— Remote {o.m, args, var, fut) for a call to method m of a remote object o 
through the proxy fut, 

— Local {o.m, args, var) for a call to method m of a local object o, 

— U nknown {o.m, args, var, fut) when it cannot be decided statically whether 
the call is local or remote. 
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3.6 Step 3: A pNet for the Behaviour of Each Active Object Class 

An activity is composed of a body (itself decomposed as we shall see later), 
a model of its queue, and a model of the proxies (future objects) for each remote 
method call in its code. The activity model is a pNet synchronising these 3 parts. 

Methods structure The essential choice for modelling the behaviour of programs 
is to get a finite, parameterized representation that take into account the pa- 
rameters of recursive methods, and the representation of objects in the store. 
We give the rational for these two points, before describing the procedure for 
building the model of an activity behaviour. 

We choose here to consider each method as a parameterized process, method 
calls being local synchronisation between specific instantiations of the processes. 
This simple scheme trivially ensures that we get a finite parameterized network. 
For each method call and for each return from a call, we generate in the activity 
pNet a synchronisation event between the 2 processes involved. 

Objects and Stores There is one common store for each activity. Each object 
creation point in the code corresponds to a number of objects in the store. If the 
static analysis can determine precisely this number, we shall use it, otherwise, 
we index the object by an integer denoting its creation rank. 

Queues The request queue of an active object runs independently of its body, 
and is always accepting arriving requests (of correct type) encoded by Qjm 
actions. It is synchronised with the object body through the services (Sjm) 
actions produced by rule DO-SERVE. 

There are several primitives for selecting requests from the queue. The most 
frequent way to filter the requests is by the request name, but the programmer 

can also build more complex selection filters, 
using the request arguments and/or the sender 
identity. He can also decide to serve the requests 
in various order or to do some global treat- 
ment on the queue after selection e.g.: serve 
Oldest (foo), serve Oldest {foo{i),i < 10), 
serve Newest {foo, bar) or serve flushNewest 
{Move{x, y)). 

The various primitives used in a given ac- 
tive object define statically a finite partition of 
the requests domain. We also collect all selec- 
tion/operation modes used in the active object code, within: Modes = {serve, 
serve AndFlush} x {Oldest, Newest, Nth}. 

The idea is that we can now model the queue as a product of independent 
processes, each encoding one set in the partition, and implementing the relevant 
operation modes. The model for each part is built in a generic way, as an in- 
stantiation of the figure above, in which m,args,pred must be replaced by the 
corresponding possible values. 



lQjm{co, f, args) 
q := put{q, < m, co, /, args >) 




< m, CO, f, args > = select [q,pred) 
in \body.Sjm{co, f,args)) 
q := update{q,pred) 




54 



Tomas Barros et al. 



The most beneficial optimisation comes from the factorisation in separate 
queues, and is computed from static analysis by collecting all service primitives 
used in a specific active object. 

Those queues will be coordinated by the automaton encoding the activity 
behaviour. The benefits come from the fact that we avoid to compute this inter- 
leaved product independently from its context. 



3.7 Step 4: A Model for the Activity Behaviour 

The procedure for building the model of a (parameterized) activity is: 

1. Compute the set of required static object classes, the XMCG, and the set 
of object instances in the store (static object creation points with their pa- 
rameters) . 

2. Build the activity pNet, with one box for each method in the XMCG, and 
one-to-one links for method calls. The activity behaviour is functional, be- 
cause there is a single thread of execution in the activity; this means that 
only one of those boxes has an initial transition that can be fired alone while 
others will have to wait to be called. 

3. For each method m in the activity, use the Procedure Method-Behav (m, 
n, XMCG), where n is the entry node of m in the XMCG, to compute the 
corresponding parameterized LTS. 



1 

2 

3 

4 

5 

6 

7 

8 
9 

10 

11 

12 

13 

14 

15 

16 

17 

18 



Method-Behav (m, n, < M, V, *Ci *t>) ' 

Aut . init = {fresh sq}; Map = 0; Caller = 0; ToDo = {< n, sq >} 
while ToDo ^ 0 

ToDo. choose < n, s > 

if Map(n) then DD-LOOP-JDIN 

else 

select~n in 

Ent(c,m,args) : DO-ENTRY 

CalKcallsin)) : DO-CALL 

PP(lab) : DO-PP 

Serve (caZZs(n) ,mset,pred,mode) : DO-SERVE 
Use(fut,val) : DO-FUTURE 

Ret(val) : DO-RETURN 

unless*'n=Ret 

let MT, N - succs{n) in 
foreach~ni in~A^ do 

fresh^Sii ToDo. Add < n^, Si > 

MT) _ , 

Aut. add" Si 6 = {sijt 



The ToDo set collects all pending MCG nodes, that need to be processed 
later, with the corresponding LTS node. Map is the mapping between nodes 
of the XMCG, and the corresponding nodes in the created LTS. For all nodes, 
MT is a meta-transition encoding the sequential intra-procedural flow. It carries 
a piece of sequential program (possibly empty) and has a number (> 1) of 
target nodes Af, from which we create an equal number of LTS nodes S. The si 
LTS node in line 18 is the terminal node created by each of the specific DO-* 
procedures (joining all branches created by the procedure when necessary). 

Each of the following node-specific procedures sets the si for branching the 
subsequent transitions, and updates the mapping Map. 
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Initialisation : The Caller object is memorised and will be used by the return 
nodes. 



DO-ENTRY (c, m, args) = 

fresh Si ; Caller =~c, Map = Map U {n 1— 


> Si} 


?Call.m(c,arqs) 

Aut . add s ^ s 1 





Sequential nodes: PP nodes in the XMCG correspond to program points, e.g. 
a label in the source code corresponding to a loop or a join in the program 
structure, or a specific passage point that the user has designated. This event 
can be made visible in the LTS if we need it for a given proof. 

DD-PP (lab) = 

Ohs{lab) / f 1 \ f -> 

if observaole(.la.h) then Aut.add s ^ {jresn si), Map = Map U {n i— ^ sij 

else"si =~s 



Call nodes : A call node has one or more call transitions, each of them can be 
remote or local, and each of them have an optional [Mix] guard, meaning that 
its true (remote or local) nature will only be determined at instantiation time. 



DD-CALL (coiis(n)) = 

fresh-fii , Map — MapU{ni— ^ si} 
foreach call in calls{n) 
match call with 



if 



"Remote (o ,m , args ,var ,fut) " : Aut.add s 

"Local (o. m, args, var) " : Aut.add s 

"Unknown(o.m,args,var,fut) " ; Aut.add s 
Aut . add s 

local-or-unknown n non-void-result (m) 

?Ret.m(o,val) . 

Aut.add~S2 ^ {jresn S3) 



]fut.Q.m(o,args) 

^ -Si 

\o.Call.m(args) 

^ {fresh S2) 

[Mix]\ fut.Q.m{o,args) 

^ Si 

[M ix]lo .Call jm (args) 



{fresh S2) 



then 

var:= val 



Return nodes : Return nodes are not marked in the node mapping: each return 
node of a method is treated separately, and generates its own ! Ret action. The 
return value val is absent for void-result methods. 



DO-RETURN (val) = 

\Caller. Ret.m(val) 



{fresh si) 



Request Service nodes : Serving a request from the local queue is similar to calling 
a method, but we have to encode the request selection mechanism. Call arcs from 
a serve node are only of Local type, and for each request m in mset, we have such 
one call arc, expressing one of the possible selection in the queue. The activity 
model is synchronised with the queue model through the ISjm message (with 
guard pred if needed); then the method m is started with the arguments gathered 
from the queue, it waits for the computation to terminate and if necessary sends 
back the return value to the caller (object o, proxy /, that were stored with the 
request). 
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Fig. 5. Automata for futures’ proxies (without or with recycling) 



DO-SERVE (calls (n) ,mset ,pred, mode) = 
fresh~si. Map = MapU{ni— si} 
foreach call in calls{n) 

match call with "Local (o ,m, args ,var) " 
if 771 G mset do 
fresh~S2, S3 

[pred]? S jm(f ,0, args ,mode) 

Aut . add s > 

if mill-result (m) then Aut.add~S3 



]body .0 all. m (this , args) 

S2 

?Ret.m(val) 

^ Si 



S3 



else 



Aut . add" S3 



? Ret.m(val) 



{fresh S4) 



lo.R.m(f,this 



,val) 



Si 



Loops: The (Loop-Join rule) applies to all types of nodes that already have 
been visited. Then the corresponding LTS node is substituted to the current 
LTS node, eventually creating loops or joins in the LTS. 



DD- JOIN-LOOP 0 = Si = Map(n) 
Aut.replace{s, si) 



Future values and utilisation : We create a future object at each remote invoca- 
tion point with a non-void result type. This future object provides the value to 
its potential use points. Thereby, we have as many ’’future objects” automatas as 
invocation points, and we synchronise those with their use points in the future 
rule. There are cases when static information garanties that a future value is 
consumed at a particular point, in which case we can recycle the corresponding 
future object (then a single automaton can be used, instead of a family indexed 
by its occurence in the store, see Fig. 5). 



DD-FUTURE (fut.val) = 



Map — Map U {n I— *■ si} 



{fresh si) 



4 Example 

We use here a part of the Producer/Consumer example from section 1 to illus- 
trate the model generation. 
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4.1 ProActive Code and Extended MCG 



The consumer and corresponding XMCG: 

public void runActivity (Body myBody) { 

{ ... 

while (true) { 

Type data = Buffer .get () ; 

System. out .printlnC'The value is " + data); 
> 

} 

> 




The buffer and corresponding XMCG: 

public void runActivity (Body body) { 
int bound; 

Type [] tab; 

{ 

while (true) { 
if (bound==0) 

service . serveOldest ( "put " ) ; 

else 

service . serveOldest () ; 

>}> 

void put (Type data) { 
tab [bound] =data; 
bound++ ; 

} 

Type get(K 

return (tab [bound — ] ) ; } 




4.2 The Generated Nets 

We illustrate the model construction with two examples : the Buffer pNet in 
Fig. 7 illustrates the model of local method calls, and its interaction with the 
queue, while the Consumer pNet in Fig. 6 illustrates the interaction with a proxy. 
For each of the methods LTSs, we have applied a simple optimisation after 
completion of the Method-Behav procedure, removing all empty transitions that 
where not part of a non-deterministic choice (removal of tau-prefix) . 
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Fig. 6 shows the pNet modelling the Consumer behaviour. Note that the data 
accessed by the Consumer is immediately consumed (the Use node in the MCG 
follows immediately the Request node). This implies that there can be only one 
’’get” future active at any time, so we use a single future in the proxy instead of 
an indexed family of futures. 

An interesting feature is that the Q_get synchronisation between the con- 
sumer root and its proxy is directly visible as a message addressed to the buffer 
process (thanks to the expressivity of synchronisation vectors); this technique 
enables us to avoid an explicit encoding of a rendez-vous protocol, that would 
introduce unnecessary interleavings. 

5 Conclusion and Directions 

We have introduced a language to describe the behaviour of communicating dis- 
tributed systems using parameterized models. The parameters in our model are 
variables that encode both: data value (such as in the theories of value-passing 
systems), and process identifiers (such as in the theories of channel-passing sys- 
tems). We argue that our models are suitable as a specification language for 
distributed systems behaviour, and for models resulting from static analysis of 
source code. We also gave a graphical representation of those models that aims 
to be used by non-specialist in formal methods; we have shown in [3] how our 
graphical models can be used to specify and verify large distributed applications. 
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Our models enable us to have a finite representation of infinite systems. They 
naturally encode the semantics of languages for distributed applications. In fact, 
we have sketched a method for constructing parameterized models for distributed 
applications built with the ProActive library. This method has been described 
in terms of algorithms, and use an extension of method call graphs obtained by 
flow analysis. Our methodology was illustrated guided by a Producer-Consumer 
system. 

We have developed a tool that makes automatic instantiations of our param- 
eterized models, we have developed a prototype of a graphical editor to design 
parameterized systems and we will integrate, in a short-term, these parameter- 
ized systems to on-the-fly model checking tools. 

Having a specification and the models generated from the source code, we 
want to check the correctness of the implementation. This check will need 
a refinement pre-order, which allows the implementation to make some choices 
amongst the possibilities left by the specification, and it should be compatible 
with the composition by synchronisation networks. 

We shall also extend the approach to take into account other features of 
the middleware, and in particular the primitives for group communication, and 
for specifying distributed security policies. Last but not least, ProActive active 
objects are also viewed as distributed components in a component framework. In 
the next version, it will be possible to assemble distributed objects to form more 
complex components. This will increase the impact of the compositionality of 
our model, and the importance of being able to prove that a component agrees 
with its (behavioural) specification. 
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Abstract. UML and SDL are languages for the development of software 
systems that have different origins, and have evolved separately for many 
years. Recently, it can be observed that OMG and ITU, the standard- 
isation bodies responsible for UML and SDL, respectively, are making 
efforts to harmonise these languages. So far, harmonisation takes place 
mainly on a conceptual level, by extending and aligning the set of lan- 
guage concepts. In this paper, we argue that harmonisation of languages 
can be approached both from a syntactic and semantic perspective. We 
show how a common basis can be derived from the analysis of the UML 
meta-model and the SDL abstract grammar. For this purpose, concep- 
tually sound and well-founded mappings from meta-models to abstract 
grammars and vice versa are defined and applied. The long term objec- 
tive is the syntactic and semantic integration of UML and SDL. The key 
to achieving this objective is a common language core, which can then 
be extended in different ways to cover further, more specific language 
concepts, and is sufficiently flexible to support future language add-ins. 



1 Introduction 

UML (Unified Modeling Language [1], [2]) is a graphical language for specifying, 
modelling and documenting software systems with widespread use in industry, 
standardised by the Object Management Group (OMG). It is a family of no- 
tations (e.g., use case diagrams, class diagrams, sequence diagrams, statechart 
diagrams, deployment diagrams) supporting different views of a system through- 
out the software life cycle. Recently, the UML 2.0 standard was finalised. The 
new standard is a major revision of UML 1.x, and introduces, amongst other 
things, better support for system structure and components. 

SDL (System Design Languages [3]) is a graphical specification language for 
distributed systems and, in particular, communication systems, standardised by 
the International Telecommunications Union (ITU). It is widely used in telecom- 
munications industry. SDL is a sophisticated set of notations (e.g., MSG-2000, 
SDL-2000, ASN.l, TTGN), supporting different system views on different levels 
of abstraction. 

With SDL-2000, several important steps towards its future harmonisation 
with UML were made. For instance, classes and associations including aggrega- 
tion, composition, and specialisation were added to the language. Furthermore, 
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composite states that are similar to submachines in UML statecharts were incor- 
porated. In turn, UML 2.0 introduced structured classes, which extend classes by 
an internal structure consisting of nested structured classes, ports and connec- 
tors. This makes it possible to model architectural aspects of systems in a fashion 
similar to SDL. 

First attempts to harmonise UML and SDL have already been made. The 
Z.109 standard [4] defines a subset of UML 1.3 [2] that has a mapping to SDL- 
2000. The UML subset is used in combination with SDL, with the semantics 
based on SDL-2000. In [-5], Selic and Rumbaugh define a transformation from 
SDL-92 to UML 1.3 extended with the Rational Rose real-time profile. 

Ultimately, these efforts are directed towards an integration of both languages 
and the corresponding notations. However, at the time being, UML and SDL still 
deviate in many ways, making it hard to see whether and when integration might 
actually be achieved. Differences range from pure syntactic aspects to semantic 
concepts, resulting from the origin of the languages. Also, it is not clear whether 
different views of a system even if expressed in notations belonging to the same 
family are consistent. 

A true integration of both languages and the corresponding notations will 
require a common syntactic and semantic core. This basis may then be extended 
in different ways, yielding a variety of language profiles. This way, the system 
developer will be enabled to model different parts of a system using different 
notations, and to combine them into a single view. 

In order to derive a common syntactic and semantic basis, the existing lan- 
guage definitions of UML and SDL should be taken as a starting point. In this 
paper, we present the results of analysing several corresponding excerpts of UML 
and SDL, compare them, and derive a common subset. This is done on the syn- 
tactical level, by defining conceptually sound and well-founded mappings from 
meta-models (used to define the abstract syntax of UML, see Section 2) to ab- 
stract grammars (used by SDL, see Section 2) and vice versa (Section 3), and 
by extracting common production rules (Section 4). Results are discussed in 
Section 5. 

2 UML Meta-Model and SDL Abstract Grammar 

The definition of a language consists of its syntax and semantics. The concrete 
syntax of a language includes separators and other constructs needed for parsing 
the language. The abstract syntax omits these details and contains only the 
elements relevant for the definition of the semantics. Both the concrete and the 
abstract syntax of a language can be defined in terms of a grammar, consisting 
of a set of production rules that define the syntactically correct sentences. 

For SDL, a concrete (textual and graphical) syntax and two abstract syn- 
taxes, ASO and ASl, are defined. The ASO is obtained from the concrete syntax 
by omitting details such as separators and lexical rules. Otherwise, is very simi- 
lar to the concrete syntax of SDL. The abstract syntax ASl is obtained from the 
abstract syntax ASO through a step of transformations followed by a mapping. 
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During the transformation, additional concepts are translated into core concepts 
of SDL as described in the standard. 

The abstract syntax of SDL is described in terms of an abstract grammar, 
similar to BNF. It consists of two kinds of production rules, namely concatena- 
tions and synonyms. A concatenation ’Ihs rhs’ describes the non-terminal 

Ihs (left hand side) as a composite object consisting of the elements denoted by 
rhs (right hand side). Optional elements are enclosed in square brackets, and 
alternatives are separated by vertical bars. The suffix describes a possibly 
empty list of elements, ’-I-’ a non-empty list and ’-set’ a set of distinguishable 
elements. A synonym ’Ihs ::=(=) rhs’ describes that the non-terminal Ihs is an 
element of the kind rhs and can not be syntactically distinguished from other 
elements of this kind. 

For the mapping described in Section 3, we assume a normal form of the 
abstract grammar, where concatenations have no alternatives on the right hand 
side. The SDL abstract grammar can be easily transformed into this normal 
form by introducing new synonyms for these alternatives. 

Below an excerpt of the ASl, the production rule State-node, is shown. State 
nodes are composite objects consisting of a state name, a save signalset, and sets 
of input nodes, spontaneous transitions, continuous signals and connect nodes. 
Optionally, a state node can have a composite state type identifier (in that case, 
the state represents a composite state of the respective type). 

State-node ::=(::) State-name 

[On-exception] 

Save-signalset 

Input-node-set 

Spontaneous-transition-set 

Continuous-signal-set 

Connect-node-set 

[Composite- state- type-identifier] 

A meta-model is a model used to define a language for the specification of 
models. In UML, this meta-model approach is used to define the language syntax. 
In particular, the abstract syntax of the language is defined using UML class 
diagrams. This approach is reflective, since class diagrams are UML models, and 
therefore described in terms of themselves. On top of the model and the meta- 
model, more layers can exist (meta-meta-models, etc.). UML uses a four layer 
meta-model structure: user objects (MO), model (Ml), meta-model (M2) and 
meta-meta-model (M3). Every element in a layer is an instance of an element of 
the direct superordinate layer. 

The UML class diagrams used for the description of the abstract syntax 
comprise packages, classes, attributes, associations and specialisation. Classes in 
the UML meta-model describe language elements. An occurrence of the language 
element in the model (Ml) is an instance of the meta-model class. Classes in the 
meta-model can be parameterised by attributes. Attributes describe properties 
of the language element described by a class. Composition between meta-model 
classes describes that a language element contains another. General associations 
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relate language elements with each other, e.g., a transition with a trigger. The 
meta-model uses packages, abstract classes and specialisation to structure the 
abstract syntax. 

3 Defining Mappings Between UML Meta-Model 
and SDL Abstract Grammar 

In this section, we define precise, conceptually sound mappings from meta- 
models to abstract grammars, and vice versa. The examples for the reverse 
mapping can be found in [6]. As it turns out, not every element of the UML 
meta-model can be mapped. Also, several meta-model elements may have the 
same representation in the abstract grammar. Therefore, the mapping is not 
completely reversible. However, it is possible to map every element of an ab- 
stract grammar to a meta-model representation. In Section 4, these mappings 
will be applied to UML and SDL to extract a common syntactical basis. 



3.1 Classes and Enumerations 

map(MM): A concrete class of the meta-model represents a language element 
of the model. E.g., the meta-model class State represents all state descriptions in 
a UML statemachine. In an abstract grammar, a language element is represented 
by a specific production rule, namely a concatenation. Therefore, a concrete 
class in the meta-model is mapped to a concatenation of the abstract grammar. 
The name of the non-terminal is derived from the class name and the package 
structure of the meta-model (see below) . The right hand side of the concatenation 
is derived from the class definition (attributes) and context (associations) as 
defined below (see 3.2, 3.3). 

An abstract class of the meta-model describes properties that are common 
to its subclasses. E.g., the meta-model class Vertex describes properties that are 
common to states and pseudo-states (initial states, . . . ). Since an abstract class 
can not be instantiated, it does not represent a language element of the model. 
Therefore, no concatenation is used in the mapping. Instead, we have decided 
to map an abstract class of the meta-model to another kind of production rule, 
namely a synonym, of the abstract grammar. In an abstract grammar, a synonym 
replaces the element on its left hand side with an element of the right hand side. 
This is a similar to abstract classes in the meta-model, which must be replaced 
by one of their concrete subclasses in a model. The name of the non-terminal is 
selected as in the case of a concrete class. The right hand side is derived from 
the context (specialisation) as described below (see 3.5). 

An enumeration in the meta-model is a set of values used to parameterise 
meta-model classes. E.g., the meta-model class Pseudostate describes different 
language elements (entry point, exit point, . . . ) of the model depending on the 
value of the attribute ’kind’ of the enumeration type PseudostateKind. Enumer- 
ations do not directly describe language elements of the model. Therefore, as in 
the case of abstract classes, no concatenation is used in the mapping. Instead, 
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Vertex 



StateMachine 



MM 



map(MM) 



«enumeration» 

TransitionKind 

internal 

local 

external 



BehSM_StateMachine ::= 
BehSM_Vertex ::=(=) 
BehSM_TransitionKind 






<=) 



enumerations are also mapped to synonyms of the abstract grammar. This pro- 
duction rule replaces the enumeration by one of its values. 

The name of the non-terminals introduced by the mappings described above 
is the qualified name of the class or enumeration. The qualified name is a se- 
quence of the packages the class or enumeration is contained in (from outermost 
to innermost) and the name of the class or enumeration, each separated by un- 
derscores. E.g., KerneLEIement is the name of the non-terminal introduced by 
the class Element in the package Kernel. The qualified name is used in order to 
avoid name clashes between equally named classes in different packages. 



Example: The following example comes from the meta-model of UML state 
machines. It describes two classes, an abstract class Vertex and a concrete class 
StateMachine. Furthermore, there is an enumeration TransitionKind. All of these 
elements are contained in the package BehaviorStatemachines (not shown), that 
we will shortly refer to as BehSM. 

StateMachine is a concrete class, and is therefore mapped to a concatenation. 
The name BehSM_StateMachine comes from the package structure and the name 
of the class. The abstract class Vertex and the enumeration TransitionKind are 
mapped to synonyms. 



map(AG): As mentioned in the mapping from meta-models to abstract gram- 
mars, concrete classes and concatenations both represent language elements of 
the model. Therefore, concatenations of the abstract grammar are mapped to 
concrete classes in the meta-model. The name of the concrete class is derived 
from the production rule (see below). 

A synonym of the abstract grammar represents a language element that does 
not appear in the model, but stands for other language elements. E.g., a Data- 
type-definition in the SDL abstract grammar is a synonym for a Value-data- 
type-definition, an Object-data-type-definition or an Interface-definition. This is 
a similar concept to abstract classes in the meta-model, which we have mapped to 
synonyms in the abstract grammar. However, it is also similar to an enumeration, 
where the enumeration stands for one of its values. Therefore, we map a synonym 
in the abstract grammar either to an abstract class or an enumeration. The exact 
mapping depends on the right hand side of the synonym (see 3.2, 3.3). The name 
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MM 


map(MM) 




«enumeration» 

TransitionKind 

internal 

local 

external 




Transition 

kind: TransitionKind 




BehSM_TransitionKind ::=(=) 
INTERNAL 
1 LOCAL 
1 EXTERNAL 

BehSM_Transition 

BehSM_TransitionKind /* kind */ 



of the class or enumeration is the name of the non-terminal on the left hand side 
of the production rule. 

3.2 Attributes 

map(MM): In the meta-model, attributes of a class represent properties of 
a language element of the model. E.g., the attribute ’kind’ of the meta-model 
class Transition describes if the transition is internal, local or external. In an ab- 
stract syntax tree, an attribute is represented as a sub-node of the non-terminal 
and corresponds to a class. We have mapped concrete classes to concatenations 
of the abstract grammar. Therefore, an attribute of a concrete class is mapped 
to a terminal on the right hand side of the concatenation. We map attributes to 
terminals since they do not need to be refined any further. The only exception is 
an enumeration type; in that case we map the attribute to a non-terminal, since 
we have mapped enumerations to synonyms and non-terminals. The name of the 
terminal is the name of the type (e.g. Boolean). The name of the non-terminal is 
derived from the name of the enumeration and the package structure, as defined 
in 3.1. 

Attributes that are marked as derived carry no additional information and 
can be omitted. E.g., the attribute ’isComposite’ of State can be derived from 
the number of associated regions. If they are not omitted, additional static condi- 
tions are needed to define the dependencies between the original and the derived 
attributes. Default values of attributes can not be mapped to the abstract gram- 
mar. They can be described by static conditions. 

Elements of an enumeration represent values of the enumeration type. A value 
in an abstract grammar is represented by a terminal. Therefore, enumeration 
elements are mapped to terminals of the abstract grammar. The name of the 
terminal is the name of the enumeration element. An enumeration is mapped 
to a synonym of the abstract grammar. Therefore, we map the terminals to the 
right hand side of the synonym corresponding to the enumeration. 



Example: The following example (again from BehaviorStatemachines) contains 
a concrete class Transition and the enumeration Transition Kind. The classes are 
mapped as described in the previous section. The attribute ’kind’ of Transition 
is an element on the right hand side of BehSM_Transition. In this special case 
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(’kind’ is an enumeration), it is a non-terminal that refers to the mapping of the 
enumeration Transition Kind. The name of the attribute is appended as a com- 
ment. The enumeration literals of TransitionKind appear as an alternative of 
terminals on the right hand side of the production rule, written in all caps for 
better distinction. 

map(AG): A terminal on the right hand side of a concatenation represents 
a property of the language element. In the meta-model, an attribute represents 
a property of a language element. The terminal is therefore mapped to an at- 
tribute of the concrete class corresponding to the concatenation. The type of the 
attribute is the name of the terminal. The name of the terminal can be chosen 
arbitrarily as long as it does not conflict with other attribute names of the class. 

A synonym with only terminals on the right hand side represents an enumer- 
ation of values. E.g., the synonym Agent-kind of the SDL abstract grammar is 
an enumeration of the values SYSTEM, BLOCK and PROCESS. Therefore, the 
terminals are mapped to enumeration values of the enumeration corresponding 
to the synonym. 

3.3 Associations 

map(MM): An aggregation or composition between two classes means that 
one language element contains or is made up of other language elements. E.g., 
a Region in a statechart contains vertices and transitions. In the same way, a node 
in an abstract syntax tree can have sub-nodes. E.g., a State-transition-graph of 
the SDL abstract grammar has a set of State-nodes as sub-nodes. Therefore, we 
map aggregation and composition to the abstract grammar so that the definition 
of the aggregated class is a sub-node of the aggregating class. This is achieved 
by adding the non-terminal corresponding to the aggregated class on the right 
hand side of the concatenation corresponding to the aggregating concrete class. 

A general association between two classes is an association between language 
elements, in which the elements play a certain role. E.g., a State is associated 
with a number of triggers, the triggers playing the role of deferrable triggers. 
In the SDL abstract grammar, two language elements are associated by identi- 
fiers. E.g., an Input-node is associated with a Signal by a Signal-identifier on the 
right hand side of the concatenation corresponding to the Input-node. Therefore, 
a directed general association is mapped to an identifier on the right hand side 
of the concatenation corresponding to the concrete class the association origi- 
nates from. An undirected general association is split into two directed general 
associations. 

An associations with the union property is the union of the associations that 
subset it. This is expressed by the property subsets. As in the case of derived 
attributes, associations with the union property are not mapped to the abstract 
grammar. 
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Example: The following example shows the abstract class Vertex and the con- 
crete classes Transition and Region. Region is composed of a Vertex called sub- 
vertex. This composition is a subset of the association ’ownedElement’ between 
two Elements. In the AST, BehSM_Region thus has BehSM_Vertex on the right 
hand side, with the name appended as a comment. Between Vertex and Transi- 
tion there are two bidirectional associations, which are split into two unidirec- 
tional associations respectively. Attributes and associations of an abstract class 
are not mapped to the corresponding synonym in the AST, since an abstract 
class is not a synonym for one of its attributes or associations. Instead, they 
are copied into the respective subclasses, as described in Section 3.5. In this 
example. Vertex has no subclasses. Therefore, we only have to map the two 
general associations ’source’ and ’target’. To distinguish between general asso- 
ciation and composition, an association is mapped to an identifier (in this case, 
BehSM_Vertex-ldentifier) on the right hand side of the corresponding production 
rule. How the identifier looks like is not further specified. It could be a qualified 
name like in the case of SDL. 



map(AG): Non-terminals on the right hand side of a concatenation can stand 
for an enumeration or a class in the meta-model. In case they represent an enu- 
meration they represent an attribute of the class (see 3.2). In case they represent 
a class, this class is a sub-node of the class corresponding to the concatenation. 
This is similar to a class in the meta-model that is composed of other classes. 
Therefore, in this case we map a non-terminal on the right hand side of a con- 
catenation to a composition in the meta-model. The composing class is the class 
corresponding to the concatenation; the composed class is the class correspond- 
ing to the non-terminal on the right hand side. The role of the classes can be 
chosen arbitrarily. 
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Table 1. Mapping of Multiplicities 



MM 


AG 


0..1 


[Name] 


0..n, 1 < n 


(as 0..*) 


0..* 


Name * 


0.. * {unique} 


Name-set 


1 


Name 


l..n, 1 < n 


(as 1..*) 


1..* 


Name -h 


1..* {unique} 


(as 0..* {unique}) 


n 


(as 0..*) 


n..m, 1 < n < m 


(as 1..*) 


n..*, 1 < n 


(as 1..*) 



An identifier on the right hand side of a concatenation identifies a language 
element that is associated with the language element described by the concate- 
nation. E.g., in the SDL abstract grammar, an Input-node is associated with 
a Signal by a Signal-identifier. Therefore, we map an identifier on the right hand 
side of a concatenation to a directed general association in the meta-model. The 
source of the association is the concrete class corresponding to the concatenation, 
according to the mapping in 3.1. The target is the concrete class corresponding 
to the language element referenced by the identifier. The role of the classes can 
be chosen arbitrarily. 

3.4 Multiplicity 

The following table defines a mapping between multiplicities in the meta-model 
and the abstract grammar. In UML, multiplicities consist of a lower bound and 
an optional upper bound, which can be infinite. The property ordered expresses 
that there is a linear order for the elements. The property unique expresses 
that no element appears more than once. In the abstract grammar, an optional 
element is enclosed by square brackets. A possibly empty list of elements is 
marked by a behind the element, a non empty list by a ’-I-’. A set of distinct 
elements is marked by the suffix ’-set’. 

Table I shows the mapping of multiplicities between meta-model and abstract 
grammar. If we use lists in the abstract grammar, the elements are ordered and 
not necessarily unique. If we use sets, they are not ordered and unique. Therefore, 
we can only map one of the properties to the abstract grammar. In this case, 
the property ordered is omitted from the mapping. 

3.5 Specialisation 

In the UML meta-model, abstract classes and specialisation are used frequently 
to capture common aspects of different classes, and as part of a meta-language 
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core reused in several standards (see UML: Infrastructure [1]). For the abstract 
syntax, abstract classes are not directly interesting, since they can not be instan- 
tiated and therefore do not appear in a model, except through their subclasses. 
Nonetheless we map them to the abstract grammar, to preserve as much of the 
structure of the meta-model as possible. 

map(MM): We have to map specialisation to the abstract grammar, and the 
fact that a specializing class inherits properties of the specialised class. The 
easiest way to do this is to copy these properties into the specializing classes 
before the mapping. This has the advantage that redefinition of properties is 
easy to realise. They are not copied to subclasses that overwrite them. 

This is done as follows: 

1. For every class that has subclasses, copy all attributes of the class and all 
associations that originate from this class to each of its direct subclasses. 

(a) An attribute is only copied to a subclass if no attribute of the same name 
already exists, i.e., if the attributed is not redefined. 

(b) An association is only copied to a subclass if it is not redefined in the 
subclass. 

2. Repeat step 1 for all subclasses that have new attributes and associations 
after the last execution of step 1. 

In the meta-model, an abstract class can take part in an association. In the 
model, an instance of a concrete class that specialises the abstract class takes 
part in the association instead. E.g., a Vertex is associated with Transitions as 
the source of these transitions. In the model, the source of these transitions is 
either a State or a Pseudostate. In the abstract grammar, we can express this 
using a synonym. We have already mapped an abstract class to a non-terminal 
and a synonym (see 3.1). To map the specialisation to the abstract grammar, 
we add the non-terminals corresponding to the direct sub-classes of the abstract 
class to the right hand side of the synonym. This means that every occurrence 
of the non-terminal (the abstract class) is replaced by a non-terminal (one of the 
subclasses) in the abstract syntax tree. 

To map specialisation to the abstract grammar, we need synonyms. On the 
other hand, a concrete class can have subclasses, but is mapped to a concatena- 
tion (see 3.1). In this case, we transform the meta-model before we perform the 
mapping. The concrete class with subclasses is replaced by an abstract class of 
the same name. The concrete class is renamed, e.g. by adding a special prefix, 
and added as a subclass of the new abstract class. The subclasses of the con- 
crete class are now subclasses of the new abstract class and the mapping can be 
performed. However, we still have to copy the attributes of the concrete class to 
its former subclasses, as described above. 



Example: The following example is taken from the package Kernel and cov- 
ers classifiers, classes and associations. Classifier is an abstract class with the 
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attribute ’isAbstract’. A classifier can be generalised by another classifier, de- 
scribed by the association named ’general’. Concrete subclasses of Classifier are 
Class and Association. The association ’superclass’ between two classes redefines 
the association ’general’. 

Before mapping to the abstract grammar, we have to copy the attributes 
and associations of the abstract class Classifier to its subclasses. The attribute 
’isAbstract’ is copied to the classes Class and Association, since no attribute of 
the same name exists. A new association ’general’ from Association to Classi- 
fier is added. The association ’superclass’ redefines ’general’, therefore no new 
association is added to Class. 

The abstract class Classifier is mapped to a synonym. Class and Association 
are direct subclasses of Classifier; therefore, we add the non-terminals corre- 
sponding to these classes on the right hand side of the synonym. 



map(AG): Non-terminals of the abstract grammar represent language ele- 
ments. A synonym of the abstract grammar with non-terminals on the right hand 
side replaces a language element by another. E.g., a Return-node in the abstract 
grammar of SDL is replaced by an Action-return-node, a Value-return-node or 
a Named-return-node. We map synonyms to abstract classes in the meta-model. 
Abstract classes can not be instantiated, but can have instances through their 
subclasses. Therefore, we map a synonym with non-terminals on the right hand 
side in the abstract grammar to a specialisation relationship. The specialised 
class is the class corresponding to the non-terminal on the left hand side. The 
specialising classes are the classes corresponding to the non-terminals on the 
right hand side. 
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3.6 Meta-Model Approach vs. Abstract Grammar Approach 

From the discussion so far, it is quite obvious that the meta-model approach to 
defining an abstract syntax is more expressive than the (context free) grammar 
approach. As a consequence, the mapping from the SDL abstract grammar to 
a meta-model is completely reversible. However, this is not the case for the 
mapping from the UML meta-model to an abstract grammar. Several elements 
of the UML meta- model can not be expressed in the abstract grammar. They are 
described in [6]. In consequence, the meta- model approach seems to be preferable 
as a basis for the harmonisation of UML and SDL. It covers and extends the 
expressiveness of abstract grammars, and thus seems to be the right choice. 
However, when it comes to implementing a language by providing tool support, 
an abstract grammar is still needed. With the mapping defined above, such an 
abstract grammar can be systematically derived. 

4 Extracting a Common Abstract Syntax 
from SDL and UML 

Translating the meta- model of UML 2.0 into an abstract grammar supports the 
comparison of the abstract syntax of UML 2.0 and SDL-2000. In particular, 
it enables us to examine how the common constructs of SDL and UML are 
refiected in common parts of the abstract syntax of both languages, and to 
extract a common abstract grammar. 

As it has turned out, some information of the meta- model is lost when it 
is mapped to an abstract grammar (see Section 3.6). However, the information 
lost is not important for the extraction, because it is not present in the abstract 
syntax of SDL. 

Instead of mapping the UML meta-model to an abstract grammar, we could 
apply the mapping from the SDL abstract grammar to a meta-model. This way, 
no information would be lost, as the meta-model is more expressive. However, the 
extraction process would not benefit from this choice. Even worse, the extraction 
would be harder, since the UML meta-model defines a large number of abstract 
classes with attributes and associations, which would not show up in the SDL 
meta-model. It would be necessary to either copy the attributes of abstract 
classes to their subclasses in the UML meta-model (as described in Section 3.5), 
or to identify common attributes and associations, and shift them to super- 
classes in the SDL meta-model. 

To relate language elements of SDL-2000 and UML 2.0 on a syntactical level, 
substantial knowledge of both languages is required. In particular, it is necessary 
to take the semantics of language elements into account. E.g., we need knowl- 
edge of the semantics of the language elements to relate the Package-name of 
a Package-definition in the abstract syntax of SDL with the String of a struc- 
tured class in the abstract syntax of UML. Also, it can be expected that for 
some of the common constructs the abstract syntax will be different, although 
the semantic is the same. In some cases, there might even be a common abstract 
syntax, although the semantics is different. 
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To extract the common abstract syntax of the two languages, we take the 
production rules for language elements that are similar in UML and SDL, e.g. 
packages, as a starting point, and compare their right hand sides. For correspond- 
ing elements in both sets of production rules that represent similar concepts, the 
production rules for these elements are compared. If they overlap, we can relate 
the two elements with each other and include them in the common abstract 
syntax. We start the extraction with very high level language elements, namely 
packages and agents/classes, before moving to language elements with a finer 
granularity. 



4.1 Packages 

Both SDL and UML have a concept of packages for grouping and reuse of el- 
ements of the specification. Both support the nesting of packages (2). The ab- 
stract syntax of UML describes the contents of a package as a set of Pack- 
ageableElements, a synonym for all elements that can be contained in a pack- 
age. SDL describes sets of the elements that can be contained in a package, 
e.g. Signal-definition-set. Common packageable elements in SDL and UML are 
agents/classes (3), signals (4) and composite states/statemachines (5). 



SDL-2000 (ASl) 


Common AS 


UML 2.0 {derived AS) 


Package-definition 

1 Package-name 

2 Package-definition-set 
Data-type-definition-set 
Syntype-definition-set 

3 Signal-definition-set 
Exception-definition-set 

4 Agent-type-definition-set 

5 Composite-state-type- 
definition-set 
Procedure-definition-set 


Package-definition 

1 Package-name 

2 Package-definition-set 

3 Signal-definition-set 

4 Agent-type-definition-set 

5 Statemachine-set 


Kernel_Package 

1 [String] 

2 Kernel_Package-set 
Kernel_PackageableElement-set 
Kernel_PackageMerge-set 
Kernel_ElementImport-set 
Kernel_PackageImport-set 

Kernel_PackageableElement :: = (=) 

4 StructuredClasses.Class 

5 BehStateMachines_StateMachine 

3 Communications_Signal 



4.2 Signals 

Signal types exist in SDL and UML to describe communication between agents/ 
objects. Signals have a name (1) and parameters, which are represented by sorts 
in SDL and properties in UML. While representing similar concepts, the abstract 
syntax of sorts and properties are different, therefore signals in the common 
abstract grammar have no parameters. 
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SDL-20()0 (ASl) 


Common AS 


UML 2.0 (derived AS) 


Signal-definition 
1 Signal-name 
Sort-reference-identifier * 


Signal-definition ::=(::) 
1 Signal-name 


Communications_Signal ::=(::) 
Kernel_Property * 

1 [String] 



4.3 Agent- type/Class 

UML 2.0 introduces structured classes, which are classes extended with internal 
structure and ports. Structured classes are semantically and syntactically similar 
to Agent- types in SDL. Both have an internal structure of properties (respec- 
tively agents, 9), connectors (channels, 7) and gates (ports, 6). Both agent-types 
and structured classes can specialise other agent-types and structured classes 
(2), however SDL only supports single inheritance while UML supports multiple 
inheritance. Behaviour is associated with an Agent-type as a State-machine- 
definition, which consists of a name and a Composite-state-type-identifier (8). 
Behaviour is associated with structured classes by a Behavior-Identifier (8). Be- 
haviour in the abstract syntax of UML is a synonym for statemachines and 
other behaviour models. Statemachines are syntactically similar to composite- 
state- types in SDL. The abstract syntax of the two languages differs slightly, 
since UML does not have a State-machine-definition. In the common abstract 
grammar, we include the State-machine-definition but discard the name associ- 
ated with it, since it does not exist in UML. 



SDL-2000 (ASl) 

Agent-type-definition 

1 Agent-type-name 
Agent-kind 

2 [ Agent-type-identifier ] 
Agent-formal-parameter * 
Data- type-definition-set 
Syntype-definition-set 

3 Signal-definition-set 
Timer-definition-set 
Exception-definition-set 
Variable-definition-set 

4 Agent-type-definition-set 

5 Composite-state-type- 
definition-set 
Procedure-definition-set 

9 Agent-definition-set 

6 Gate-definition-set 

7 Channel-definition-set 

8 [ State-machine-definition 

] 

State-machine-definition 

State-name 

8 Composite-state-type- 
identifier 



Common AS 
Agent-type-definition 

1 Agent-type-name 

2 [Agent-type-identifier] 

3 Signal-definition-set 

4 Agent-type-definition-set 

5 Statemachine-set 

9 Agent-definition-set 

6 Port-definition-set 

7 Channel-definition-set 

8 [Agent-behaviour] 

Agent-behaviour 
8 Statemachine-identifier 



StructuredClasses.Class 

1 [string] 



KerneLClassifier-Identifier-set 

2 StructClasses_Class-Identifier-set 
[KerneLType] 
Kernel_ElementImport-set 
Kernel_PackageImport-set 
KerneLConstraint-set 
Kernel_Behavior-set 

8 [Kernel_Behavior-Identifier] 
Boolean /*isActive*/ 
Communications_Reception-set 

6 Ports_Port-set 

7 CompStruct_Connector-set 

9 IntStruct_Property-set 
Kernel_Property * 
KerneLClassifier-set 
KerneLOperation * 



KerneLClassifier ::=(=) 

4 StructuredClasses.Class 

5 BehStateMachines_StateMachine 
3 Communications_Signal 



UML 2.0 (derived AS) 
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4.4 Channel/Connector 

Channels/connectors connect gates/ports. In SDL, a channel has one or two 
channel-paths. In case of two channel-paths, the channel is bi-directional and the 
originating gate of the first path is the destination gate of the second path and 
vice versa. In UML, the connector connects two or more ports. In the common 
AS, a channel is a set of channel-ends (2), which is a pair of ports (3). No 
direction is specified. 



SDL-20()0 (ASl) 


Common AS 


UML 2.0 (derived AS) 


(Jhannel-detinition 


Channel-definition 


IntStruct.Connector ::=(::) 


1 Channel-name 


1 Channel-name 


IntStruct.Connector-Identifier 


[NODELAY] 


2 Channel-end-set 


2 Ports.ConnectorEnd * /* 2..* */ 


2 Channel-path-set 


Channel-end 


[Kernel_Association-Identifier] 


Channel-path 


3 Port-identifier 


1 [String] 


3 Originating-gate 


3 Port-identifier 


[Kernel.Type] 


3 Destination-gate 




Ports.ConnectorEnd 


Signal-identifier-set 




3 [IntStruct.ConnectableElement- 






Identifier] 



4.5 Gate/Port 

Gates/ports are endpoints for channels/connectors. Gates specify valid signals 
for both directions, while ports have required and provided interfaces (2, 3). 



SDL-20()0 (ASl) 


Common AS 


UML 2.0 (derived AS) 


Gate-definition ::=(::) 

1 Gate-name 

2 In-signal-identifier-set 

3 Out-signal-identifier-set 


Port-definition ::=(::) 

1 Port-name 

2 Signal-identifier-set 

3 Signal-identifier-set 


Ports_Port ::=(::) 

3 Interfaces Jnterface-Identifier- 
set 

2 Interfaces Jnterface-Identifier- 
set 

Ports_Port-Identifier-set 
IntStruct.ConnectorEnd-set 
1 [String] 



4.6 Composite-state- type/Statemachine 

Composite-state-types as well as statemachines have a name (1), a sequence of 
parameters (3) and an identifier of the composite-state-type/statemachine that 
they specialise (2), if any. In UML, a statemachine has one or more regions 
that contain states and transitions. The equivalent in SDL is a Composite- 
state-graph (one region) or a State-aggregation-graph (two or more regions). 
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A Composite-state-graph contains a State-transition-graph which contains the 
states of the Composite-state-type. A Region in UML maps to a State-transition- 
graph in SDL. Both contain the states (5) and transitions of the composite- 
state-type/statemachine. Multiple regions are not included in the common AS, 
because of the different syntax and semantics in SDL and UML. The common 
AS for Statemachines can be found in [6]. 

4.7 Agent/Property 

Agents and properties are both instances of a type (2) (agent-type in SDL, 
structured class in UML). Both specify upper and lower bounds for the number 
of instances (3). While the lower bound in UML is optional, it is required in 
SDL. 



SDL-2000 (ASl) 


Common AS 


UML 2.0 (derived AS) 


Agent-definition 

1 Agent-name 
Number-of-instances 

2 Agent-type-identifier 

Number-of-instances 

3 Initial-number 

3 [Maximum-number] 

Initial-number ::=(=) Nat 
Maximum-number ::=(=) 
Nat 


Agent-definition 

1 Agent-name 

2 [Agent-type-identifier] 
Number-of-instances 

Number-of-instances 

3 [Initial-number] 

3 [Maximum-number] 

Initial-number ::={=) Nat 
Maximum-number ::=(=) 
Nat 


IntStruct_Property 

Kernel_AggregationKind 
Kernel_Property* /*subset*/ 
Kernel_Property* /*refined*/ 
[Kernel.ValueSpecification] 
[Kernel_Association-Identifier] 

1 [String] 

2 [Kernel.Type-Identifier] 

3 [Kernel.ValueSpecification] 

3 [Kernel.ValueSpecification] 

3 . . . 



4.8 State- node/state 

State-nodes in SDL are similar to states in UML, however the syntax is different. 
Both have a name (1) and an identifier of the composite-state- type/statemachine 
that is the submachine of this state (2), if any. States are the source of transitions, 
but in SDL these transitions are associated with the trigger of the transition 
(Input-node) and in UML with the state itself. The common AS for States can 
be found in [6]. 

5 Conclusions and Outlook 

With regard to recent language developments, harmonisation and finally integra- 
tion of languages are becoming urgent topics. With more notations being used 
during the development of a given system, the question whether these views are 
consistent is gaining importance. Also, in the context of large systems, the use 
of a mix of notations is getting more likely. Standardisation work to harmonise 
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UML and SDL is an important effort towards the objective of having a set of 
languages that can be used together. 

In this paper, we have argued that the harmonisation of languages requires 
a common syntactic and semantic basis. Following this line, we have first de- 
fined conceptually sound and well-founded mappings from meta-models - used 
to define the abstract syntax of UML - to abstract grammars - used by SDL -, 
and vice versa. By applying these mappings, we have then extracted common 
production rules, arriving at a common abstract grammar for several language 
constructs. While the results were encouraging for structural language elements, 
it turned out that the coverage was below expectations for behavioural con- 
structs. From this experience, we have drawn the conclusion that an extraction 
on a purely syntactical basis is not sufficient. 

In [6], we have therefore compared language elements on a semantic basis. 
For this comparison, we chose UML statecharts and SDL process graphs, respec- 
tively. UML statecharts have a complete semantics with few variation points. 
Several attempts to formally define the behaviour of statecharts exist, e.g. [7]. 
The syntactic comparison of UML and SDL revealed that the abstract syntax 
of statecharts and process graphs is very different. However, there are several 
language elements in both languages that have a similar notation and represent 
similar concepts, despite major syntactic differences. The semantic comparison 
showed that there is indeed potential for the harmonisation of UML and SDL. 
However, it also revealed that without a common formal basis, the results that 
can be obtained are of limited value. 

We finally conclude that future work should be directed towards a common 
semantic core for UML and SDL, with the intention of having extensions of this 
core to cover further, language specific concepts. Both languages are complex 
and sophisticated, so this will definitely not be a simple task. However, our 
experience with the definition of the SDL formal semantics [8] has shown that 
this kind of work provides valuable feedback to the language designers, finally 
leading to an even better language. 

In a related work, Fischer et al [9] describe a way to generate meta-models 
from BNF grammars and demonstrate their approach for the abstract syntax 
of SDL-2000. To capitalise on the advantages of meta- models, they introduce 
abstract concept definitions and transform generated concrete elements to spe- 
cialisations of abstract elements. 

References 

[1] OMG Unified Modelling Language Specification: Version 2.0 (2003) 61, 70 

[2] OMG Unified Modelling Language Specification: Version 1.3 (1999) 61, 62 

[3] ITU Recommendation Z.lOO: Specification and Description Language. Geneva 
(1999) 61 

[4] ITU Recommendation Z.109: SDL combined with UML. Geneva (2000) 62 

[5] Selic, B., Rumbaugh, J.: Mapping SDL to UML. Rational Software Whitepaper. 
(1999) 62 



78 



Rudiger Grammes and Reinhard Gotzhein 



[6] Grammes, R., Gotzhein, R.: Towards the Harmonisation of UML and SDL - Syn- 
tactic and Semantic Alignment Technical Report 327/03, Technical University 
of Kaiserslautern (2003) 64, 72, 76, 77 

[7] Borger, E., Cavarra, A., Riccobene, E.: Modeling the dynamics of UML State 
Machines. In Gurevich, Y., Kutter, P., Odersky, M., Thiele, L., eds.: Abstract 
State Machines. Theory and Applications, Springer- Verlag (2000) pp. 223-241 
77 

[8] Glasser, U., Gotzhein, R., Prinz, A.: The Formal Semantics of SDL-2000 - Status 
and Perspectives. Computer Networks 42 (2003) pp. 343-358 77 

[9] Fischer, J., Piefel, M., Scheidgen, M.: A Metamodel for SDL-2000 in the Context 
of Metamodelling ULF. In: SAM’04. (2004) 77 



Localizing Program Errors 
for Cimple Debugging 



Samik Basu^, Diptikalyan Saha^, and Scott A. Smolka^ 

^ Department of Computer Science 
Iowa State University, Ames, lA 50014 
sbasuScs . instate . edu 
^ Department of Computer Science 
State University of New York at Stony Brook, Stony Brook, NY 11794 
{dsaha, sasjOcs . sunysb . edu 



Abstract. We present automated techniques for the explanation of 
counter-examples, where a counter-example should be understood as 
a sequence of program statements. Our approach is based on variable 
dependency analysis and is applicable to programs written in Cimple, 
an expressive subset of the C programming language. Central to our 
approach is the derivation of a focus-statement sequence (FSS) from a 
given counter-example: a subsequence of the counter-example containing 
only those program statements that directly or indirectly affect the vari- 
able valuation leading to the program error behind the counter-example. 
We develop a ranking procedure for FSSs where FSSs of higher rank 
are conceptually easier to understand and correct than those of lower 
rank. We also analyze constraints over uninitialized variables in order to 
localize program errors to specific program segments; this often allows 
the user to subsequently take appropriate debugging measures. We have 
implemented our techniques in the FocusCheck model checker, which 
efficiently checks for assertion violations in Cimple programs on a per- 
procedure basis. The practical utility of our approach is illustrated by 
its successful application to a fast, linear-time median identification al- 
gorithm commonly used in statistical analysis and in the Resolution Ad- 
visory module of the Traffic Collision Avoidance System. 



1 Introduction 

Model checking [22, 7] has recently made significant inroads in the domain of 
software verification [12, 18, 3, 11, 16, 4]. In this setting, model checking typi- 
cally follows a three-step iterative process of abstraction, verification and refine- 
ment [24, 2, 17, 6]. First, given a system S, a finite-state abstraction S' of S is 
generated. Then, S' is verified with respect to the given property and a counter- 
example (sequence of program statements) is generated should a violation occur. 
Finally, S' is refined in case the counter-example is spurious (infeasible in S). 
The three steps are iterated until a feasible counter-example is identified or the 
abstract system satisfies the property. 
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FSSi Assumptions: gotlock 1 



1 


int gotlock, lock; 


13: 


2 


bool error = false; 


14: 


3 


int main() { 


15: 


4 


lock = 0; 


16: 


5 


if (*) { 


6 


while (*) { 


17: 


7 


if (*) { 


18: 


8 


getlock(); 


19: 


9 


gotlock-l — h; 


20: 


10 


: bigProcedure 




11 


: if (gotlock 




12 


: rellock();}} 


22: 



void getlock() { 
if (lock — — 0) 
lock+ + ; 

else error = true; 

void rellock() { 

if (lock 1) 

lock—; 

else error = true; 



lock=0 



11: got- 2 

}ock==l:true 

FSS 2 Assumptions. 



k lock==l:false 
3: error=true 

gotlock != 0 



14: 

15: 



lock=0 



9: gotlock-|--|-; 

11: got- 

lock==l:false 
6 : 



lock==0:true 

lock-|--|- 



(a) (b) 

Fig. 1. Simple locking program from [17] 



lock==0:false 

error=true 



In the event a feasible counter-example is generated, the user is left with 
the task of identifying the cause of the counter-example and taking appropriate 
corrective or debugging measures. However, the complex behavior of software 
systems, owing to the presence of complicated data and control structures, makes 
the process of decoding counter-examples extremely tedious, if not impossible. 

To address this state of affairs, we present two automated techniques for 
effective error-reporting. The first of these is aimed at ranking counter-examples 
such that those counter-examples of higher rank are easier to understand and 
debug than those of lower rank. The second is a technique for localizing errors in 
programs to specific program regions, again allowing for effective identification 
and correction of program errors. 

Our approach is based on variable dependency analysis and is applicable to 
programs written in Cimple, an expressive subset of the C programming language. 
Central to our approach is the notion of a focus-statement sequence (FSS), intro- 
duced by us in [-5] . A FSS is a subsequence of a counter-example containing only 
those program statements that directly or indirectly affect the variable valuation 
leading to the program error behind the counter-example. As discussed further 
in Section 2, our FSS technique can thus be seen as an application of program 
slicing. Besides making counter-examples easier to understand by eliminating 
unnecessary details, FSSs can also be used to efficiently determine the feasibility 
of counter-examples, as the feasibility of the sequence of operations in an FSS 
implies the existence of a feasible counter-example. 

Being based on variable dependency analysis, our approach also successfully 
identifies the constraints or assumptions over uninitialized or input variables 
necessary for the feasibility of a FSS. Such information can be used to understand 
program behavior in the context of different variable initializations. We have 
also developed the FocusCheck model checker for Cimple. It identifies all feasible 
counter-examples in a given Cimple program and presents these to the user in a 
precise and informative manner in terms of their FSSs and assumption sets. 
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Consider first our technique for ranking counter-examples. The basic idea 
behind this technique is to rank FSSs in terms of their length and the number 
of variables in their assumption sets. In [10], Engler and Ashcraft alluded to the 
importance of ranking counter-examples for easy inspection of deadlock errors 
in multi-threaded programs. In a similar vein, we order FSSs such that those of 
higher rank correspond to errors that are conceptually easier to understand and 
debug than those of lower rank. 

Figure 1(a) presents a simple locking program correct behavior of which 
requires strict alternation between invocations of getlockO and rellockO; a vi- 
olation occurs if error=true in any execution sequence of the program. The con- 
ditional construct if (*) is semantically equivalent to non-deterministic choice, 
required for representing conditional expressions whose variables are abstracted 
away to obtain finite data domain program. The FocusCheck model checker 
identifies two counter-examples in terms of their FSSs and assumption sets 
(Figure 1(b)). The FSSs returned by FocusCheck are significantly smaller than 
the counter-examples from which they are derived as it discards program seg- 
ments (e.g. the statements of bigProcedureO) that do not affect the valuation 
error=true. Variable dependency analysis tells us that in this case, the focus 
statements are those involving variables gotlock, lock and error. For each FSS 
returned by FocusCheck, the line numbers of the program statements in the FSS 
are given; the program statement itself is also given if it represents an operation 
on a variable of interest; e.g., statement lock=0 at line 4 of FSSi. 

Our ranking procedure identifies the shorter of the two FSSs — FSSi compris- 
ing seven program statements, four of which are operations on the variables of 
interest — as the higher-ranked FSS. This directs the user to inspect FSSi before 
FSS 2 . The user is also provided with the corresponding assumption set which 
reveals that the program behaves incorrectly if gotlock is initialized to 1; i.e., 
the error manifests when the condition at line 11 evaluates to true. Corrective 
measures therefore involve the appropriate initialization of gotlock (negate the 
assumption) in one of the statements leading to the statement at line 11. Rank- 
ing FSSs and their assumption sets narrows down the erroneous region in the 
program under investigation, and assist the user in taking corrective measure by 
inserting the assignment gotlock=0 after line 5 or line 6. 

Consider next our technique for localizing errors to specific program regions. 
This technique is based on the observation that in many practical scenarios, 
a single error in a program can lead to multiple counter-examples, owing to 
the program’s branching behavior. Given a set of FSS, we generate a reduced 
set of focus-statement sequences by discarding the differences and analyzing the 
commonalities among the FSSs. 

To illustrate our technique for localizing errors in programs, consider the 
Cimple program of Figure 2(a). The program is intended to compute the mini- 
mum and maximum of three integer variables but contains an obvious typo at 
line 6 (marked in the figure) : the assignment max=y should instead be min=y. The 
error condition is satisfied if the minimum or the maximum is set to an incor- 
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1: int main() { 

2: int x, y, z; bool error=false; 

3: int min=x, max=x; 

4: if (max < y) max=y; 

5: if (max < z) max=z; 

6: if (min > y) max=y; < 

7: if (min > z) min=z; 

8: if !(min<x A min<y A min<z A 

max>x A max>y A max>z A) 
9: error=true;} 



FSSi 

Assumptions: 
x>y, x<z 
3: min=x 
6: min>y:true 
6: max=y 
7: min>z:false 
8 : 

9 : 

Error: 

max=y, min=x 



(a) 



FSSa 

Assumptions: 
x>y, x>z, z>y 
3: min=x 
6: min>y:true 
6: max=y 
7: min>z:true 
7: min=z 
8 : 

9 : 

Error: 

max=y, min=z 

(b) 



FSSa 

Assumptions: 
x>y, x>z, z<y 
3: min=x 
6: min>y:true 
6: max=y 
7: min>z:true 
7: min=z; 

8 : 

9: 

Error: 

max=y 



Fig. 2. MinMax example from [13] 



rect value. FocusCheck produces three FSSs corresponding to the three possible 
erroneous program behaviors (Figure 2 (b)). 

Our technique for localizing program errors is based on the elimination of 
a constraint and its negation, should they appear in two different assumption 
sets; it is easily shown that such a pair of constraints is irrelevant to the cause 
of the error. In the example, our technique first eliminates the constraints z>y 
and z<y from the assumption sets of FSS2 and FSS3, respectively. FSS3 is then 
discarded, being now identical to FSS2 in terms of its assumption set and line 
numbers. FSSi and FSS2 contain x<z and x>z, and we delete these constraints 
from their respective assumption sets. The remaining constraint in the assump- 
tion sets of FSSi and FSS2 is x>y. We project x>y on both the FSSs and identify 
the if-block at line 6 as the region containing the error. 

An important aspect of our technique for generating FSSs is that it proceeds 
in a modular fashion, handling each procedure in the program independently of 
the others. Specifically, our technique seeks to minimize the overhead of analyz- 
ing a procedure if it has been invoked from multiple call sites and each of these 
call sites are present in the counter-example sequence. Central to our technique 
is the summarization of each procedure with respect to the valuation of global 
variables. 

Our techniques for ranking FSSs and for localizing program errors allow the 
user to view counter-examples at different levels of granularity and detail (Fig- 
ure 3 ) . At the lowest level, the user is presented with the entire counter-example 
sequence. At the intermediate levels, the user sees the FSS of the counter- 
examples, ordered in terms of their relative complexity. At the highest level, 
reduced sets of focus statements are identified on the basis of the constraints in 
their assumption sets. As one moves to higher levels, information is organized 
and/or minimized without compromising its usefulness. 



Contributions and Organization of the Paper. In summary, the main 
contributions of the paper may be seen as follows: 
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Fig. 3. Viewing counter-examples at different levels of detail 



1. We present a hierarchy of automated techniques aimed at allowing users to 
effectively ascertain the root cause of a program error. To the best of our 
knowledge, this is the first effort to organize error explanation at different 
levels of granularity. 

2. Focus-statement sequences, introduced in [5] and reviewed in Section 2, use 
variable dependency analysis to make counter-examples much easier to com- 
prehend by discarding unnecessary details. We introduce in Section 3.1 a pro- 
cedure for ranking FSSs such that FSSs higher in the ranking correspond 
to errors that are conceptually easier to understand and debug than those 
lower in the ranking. 

3. Our technique for generating a reduced set of FSS from a given set of FSSs 
and their assumptions proceeds by discarding the differences and analyzing 
the commonalities among the given FSSs (Section 3.2). It can significantly 
aid the user in localizing the region within a program containing the error 
under investigation. 

4. We have implemented our error-localization technique in the FocusCheck 
model checker. At its core, the model checker performs reachability anal- 
ysis of programs to generate all possible feasible counter-examples in terms 
of their FSSs (Section 4). Reachability analysis is performed in a modular 
fashion by summarizing the effects of a given procedure independently of all 
other procedures (Section 3.3). 

5. We demonstrate the effectiveness of our technique by analyzing the resolu- 
tion advisory module (RA) of the traffic collision avoidance system (TCAS) 
(Section 5). 

2 Preliminaries 

In this section, we provide a brief overview of our technique for extracting focus- 
statement sequences from counter-examples [5]. Given a program and a cor- 
rectness assertion, a counter-example is a sequence of statements executed by 
the program leading to a violation of the assertion. A focus-statement sequence 
(FSS) is a subsequence of a counter-example such that each statement in the 
subsequence directly or indirectly affects the variable valuations responsible for 
the assertion violation in the program. 
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1: int gotlock, lock; 

2: void main() { 

3: int old, new; 

4: lock = 0; 

5: if (*) { 

6: while (*) { 

gotlock = 0; 

8: if (*) { 

9: getlock(); 

10: gotlock = gotlock + 1; 

11 : } 

12: if (gotlock == 1) 

13: rellock(); 

14: } 

15: } 



16; lock = 0; 

17; bigProcedure() ; 

18; while (new!=old) { 
19; getlock(); 

20; new = old; 

21; if (•) { 

22; rellock(); 

23; new = new + 1; 
24; } 

25; } 

26; rellock(); 

27; return; 

28; } 



Error Condition Counter-Example 



29: void getlock() { 

30: bool error = false; 

31: if (lock == 0) 

32: lock = 1; 

33: else error = true; 

34: return; 

35: } 

36: void rellock() { 

37: bool error = false; 

38: if (lock == 1) 

39: lock = 0; 

40: else error = true; 

41: return; 

42: } 

43: void bigProcedureQ {. . 

Focus-Statement Sequence 



error = true 
(b) in rellock() 
error = true 
in getlock() 



(4, 5, 6, 7, 8, 9, 30, 31, 32, 34, 10, 12, 13, 37, 38, 

39, 41, 16, 17, . . ., 18, 26, 37, 38, 40) 

(4, 5, 6, 7, 8, 9, 30, 31, 32, 34, 10, 12, 13, 37, 38, 39, 41, 

16, 17, . . ., 18, 19, 30, 31, 32, 34, 20, 21, 18, 19, 30, 31, 33) 



<16, 18, 26, 38, 40) 



<16, 18, 19, 31, 32, 

34, 20, 18, 19, 31, 33) 



Fig. 4. (a) The locking example (expanded version) (b) Counter-Examples and FSS 



Focus- Statement Sequences: Slicing Counter-Examples. Our technique 
for identifying FSSs, which are semantically dependent, possibly noncontiguous, 
program segments, is based on program slicing [9, 19]. Counter-examples are 
generated during model checking via reachability analysis from the start state of 
the program to a state violating the correctness condition. Reachability analysis 
is also used to record the dynamic control and data dependencies at each state- 
ment. Note that the last statement of a counter-example is responsible for the 
violation of correctness condition. A statement in a counter-example is classified 
as focus statement if it directly or indirectly affects the last statement in the 
counter-example. That is, a FSS is obtained from a counter-example sequence S 
by slicing S, using the last statement in S as the slicing criterion. 

Definition 1 (Focus Statement). Given a counter-example sequence S = 
{si, S 2 , ■ ■ ■ , Sn) where Si denotes the i-th program statement along with its line 
number and Sn is the last statement in the counter-example, Sj is said to be 
a focus statement if any one of the following holds: 

1. Sj is in the slice of S w.r.t. slicing criterion Sn', 

2. Sj is a call or return statement with at least one focus statement in the body 

of the called procedure. 

Our slicing method for extracting FSSs from counter-examples works as fol- 
lows. We perform backward exploration from the last statement s„ of a counter- 
example sequence S. A set Error is maintained during the analysis, containing 
the line numbers of the statements and variables that affect s„. Error is gener- 
ated from the sets control(si) and data(si) for each statement Si in S, represent- 
ing control and data dependencies at Si, respectively. Statement Si is control- 
dependent on those conditional statements whose line numbers are present in 
control(si), while Si depends on the variables in data(si). 
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For the first of the two counter-example sequences given in Figure 4(b), the 
set Error is initialized to {38}, as the last statement at line 40 of the counter- 
example has control(40) = {38}. As backward analysis proceeds, the statement 
at line 38 is encountered with Error = {38}; therefore, the statement at line 38 
is classified as a focus statement and Error is updated by removing 38 and 
introducing the variable lock (lock G data(38)). The next statement reached in 
the backward exploration is the one at line 37 (error=true). However, the variable 
error ^ Error. Therefore the statement at line 37 is not a focus statement and 
the Error set is unaltered. Backward exploration terminates if set Error is empty 
or all the statements in the counter-example have been analyzed. The focus- 
statement sequences identified in this manner are given in Figure 4(b) alongside 
their corresponding counter-example sequences. 



Feasibility of Counter-Example Sequences. The behavior of a program 
typically depends upon the valuation of variables that are inputs to the pro- 
gram. If an input variable has an infinite domain, say the integers, reachability 
analysis is typically performed by leaving the operations on these variables un- 
interpreted. For example, the operations at lines 18, 20 and 23 in Figure 4(a) 
are uninterpreted and forward reachability is performed by considering all possi- 
ble (boolean) valuations of the conditional expression at line 18. This approach 
leads the model checker to consider both branches of the conditional expression, 
whereas in reality only one of the branches is feasible. This results in infeasible 
counter-examples in the output of the model checker. Typically, feasibility anal- 
ysis involves considering each counter-example to determine whether all the op- 
erations in the counter-example are consistent in the original source program. In 
contrast, we reduce the overheads of feasibility analysis by reducing (a) number 
of counter-examples to be checked and (b) number of operations to be checked 
for consistency. 

These reductions are achieved by observing that given an FSS F compris- 
ing a feasible sequence of operations, there exists at least one feasible counter- 
example C with F as its subsequence. To check the feasibility of a counter- 
example, we therefore check the feasibility of the sequences of operations in 
the counter-example’s FSS. Note that the length of a FSS is often less than 
that of the corresponding counter-example making feasibility checking of the 
former more efficient than the latter. Furthermore, if multiple counter-examples 
correspond to the same FSS, proving/disproving feasibility of all these counter- 
examples is performed by checking for feasibility of a single FSS. 

Referring back to our example of Figure 4, the second FSS is infeasible due to 
the infeasibility of the operation at line 20 followed by the operation at line 18. 
The first FSS, however, is feasible. FSSs can therefore be used to both shorten 
counter-examples by eliminating unnecessary details and to effectively discard 
infeasible execution sequences. 
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3 Debugging Cimple Programs 

3.1 Ranking the Counter-Examples 

In many practical settings, a single error can force a program to behave erro- 
neously in multiple ways leading to the generation of multiple counter-example 
sequences. For example, a single error in each of the programs of Figures 1 and 2 
(missing initialization and incorrect assignment, respectively) generates more 
than one counter-example. While it is difficult, if not impossible, to localize the 
cause of multiple counter-examples to one single parameter in a program, it is 
possible develop techniques that will effectively guide the users toward mak- 
ing the correct choice in debugging programs. Ranking counter-examples on the 
basis of focus-statement sequences and their assumption sets is a methodology 
where error traces are sorted in terms of their complexity. 

Definition 2 (Rank). Given two FSSs F\ and F 2 , F\ is said to be of higher 
rank than F 2 , denoted by Fi > F 2 , if: 

1. the length of F\ is less than that of F 2 or 

2. the length of F\ is equal to the length of F 2 and the number of variables in 
the assumptions of F\ is less than number of variables in the assumptions 
of F 2 . 

Definition 2 defines a partial order over FSSs. Higher ranked FSSs are more 
likely to be easier to parse and understand than the lower ranked ones. The 
rationale for selecting the two ranking criteria is based on the following observa- 
tions. A user can potentially parse a smaller sequence of focus statements than 
a longer one. If two FSSs involve an identical number of statements, the one 
which requires assumptions over a fewer number of variables for its feasibility is 
potentially simpler to understand than the one requiring constraints over more 
variables. The involvement of a fewer number of variables in an assumption set 
means that a fewer number of program variables are affected by the assump- 
tions and, therefore, the user will be required to concentrate on a fewer number 
of operations on variables in order to track down the error. 

3.2 Localizing Program Errors Using Assumption Sets 

In this section, we provide a methodology to further minimize the sequence of 
statements in each FSS that the user is required to inspect in order to find the 
potential cause of an error. Our objective is to localize the program error to 
a specific segment of an FSS. We show that in certain scenarios, our technique 
can identify the exact program statement that is the cause of the error, and 
provide useful feedback to the user about a possible remedy. 

Our approach is based on algorithm Reduce given in Figure 5; it performs 
a reduction on a given set of FSS-assumption set pairs followed by a projection 
of the resulting assumption sets to their corresponding FSSs. 
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Input: A set S of FSSs Fi,F 2 ,...,F„ and their corresponding assumption 
sets Ai,A 2 ,...,An. Output: Reduce(S'). 

1. Initially Reduce(S') = S. Repeat Steps 2 and 3 till no change in Reduce(S'). 

2. If there exits a constraint c in a unique Ai and its negation -ic in a unique Aj, 
i ^ j, then delete c from Ai and -ic from Aj. Iterate this step until no such c is 
found. 

{reduction by eliminating eomplementary assumptions) 

3. If there exist in Reduce(5') identical FSSs Fi and Fj with identical assumption 
sets Ai and Aj, i j, remove any one of these FSS-assumption set pairs from 
Reduce(5). 

{reduction by eliminating identical FSS-assumption pairs) 

4. Project each Ai in Reduce(S') to its corresponding FSS Fi as follows. 

5. Start with statement Sk, fc = 1, the first statement in Fi and repeat the following 
cases. 

(a) Sk is a conditional statement with conditional expression c: 

1. if c ^ Ai or -ic ^ Ai then mark all focus statements in the block con- 
taining Sk and go to step 4 
ii. else fc-l— I- 

(b) Sk is an assignment statement x = y {call statements are considered as 
assignments of actual parameters to the corresponding formal parameters) 

i. if 3c G Ai involving y then add the new constraint over x in Ai by repli- 
cating constraints over y and replacing i/ by a; in the replication. fc-|— |- 

ii. if 3c G Ai involving x then delete c from Ai. 

(c) If Sk is the last statement of Fi, mark the entire Fi; go to step 4. 



Fig. 5. Algorithm Reduce 



Definition 3 (Reduced Set of Focus Statement Sequences). A set of 

focus-statement sequences {F\,F 2 , . . ■ , F„}, where each Fi is paired with assump- 
tion set Ai, is said to be reduced if the following conditions hold: 

1. If c is a constraint in Ai, then ~^c is either not present in any Aj or is present 
in at least two Aj (j ^ i) (reduction of assumptions). 

2. yi,j{i j) ^ {Fi ^ Fj y Ai Aj) (reduction of FSSs). 

3. A sequence of statements (si^, . . . , is marked in each FSS Fi such 

that the outer-most conditional expression^ over input variables in Fi can- 
not be evaluated using the constraints present in Ai (Neighborhood of Error 
Statements) . 



Eliminating Complementary Assumptions Recall that assumption sets 
represent the constraints on uninitialized or input variables necessary for the 

^ A conditional expression is outer-most in an FSS if it appears in the first conditional 
statement in the FSS 
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feasibility of a counter-example sequence. Specifically, assumptions represent 
the constraints necessary to validate the conditional expressions present in the 
counter-example. Our technique for eliminating complementary assumptions 
from a set of FSSs is based on the following observation: 



If a constraint c and its negation ~^c appear in exactly two distinct assump- 
tion sets, then c and ^c are most likely generated from the same conditional 
statement which has exactly one FSS for each of its branches. 

There are three possible ways in which the above observation holds: 

(a) Error statement followed by a conditional. Consider first the case 
where an error in a program is caused by an incorrect assignment that is 
followed by a conditional block. If the assignment affects statements in both 
branches of the conditional block and if these statements affect the assertion 
violation, then two FSSs are generated. Each FSS is accompanied by an 
assumption set containing the constraint required to obtain the appropriate 
valuation of the conditional expression; i.e., a constraint and its negation 
appear in two different assumption sets. 

(b) Error in a conditional expression. An error caused by an incorrect 
conditional expression also produces at least two FSSs. This is due to the fact 
that both branches in the conditional lead to the assertion violation. Thus, 
each branch leads to the generation of an FSS along with an assumption 
set containing the constraint required for the corresponding valuation of the 
conditional expression. 

(c) Errors in both branches of a conditional block. This case corresponds 
to the situation where there are errors in both branches of a conditional 
block. 

In all of the above cases, the pair under consideration (a constraint c and its 
negation appearing in two different assumption sets) can be safely classified as 
uninteresting constraints. The reason for this is that negating the conditional ex- 
pression in the program that generated c and ~^c followed by reachability analysis 
of error state will generate the same set of FSSs. In case the pair of constraints 
is generated from two different conditional statements our method will localize 
the bug in an ancestor block of the block containing the error. This impreci- 
sion can be removed by associating program location with each assumption and 
eliminating complementary assumptions only if they are generated at the same 
program location. 

Another important feature of the constraint pair is that they must appear 
in exactly two assumption sets. The requirement of exactly two instead of at 
least two assumption sets has its root in the following observation. Suppose 
there are two assumption sets containing constraint c and a single assumption 
set containing ^c; i.e., there are two FSSs corresponding to constraint c and 
one FSS corresponding to ~^c. In this case, it is most likely there are errors 
present in both branches of a conditional block with conditional expression c 
(or ^c) (see item(c) above). Further, as there are multiple FSSs corresponding 
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(a) 




Fig. 6. NESTs are the focus statements in the outer and inner blocks for different bug 
positions 



to c, the error is present in a block nested in the then-branch or else-branch of 
the conditional. Our aim is to localize the error in the block nested inside the 
conditional statement. As such we do not discard the constraints c and ^c. 

Removal of a constraint and its negation from two assumption sets might 
make these FSSs and their corresponding assumption sets identical; one of of 
these FSSs can be safely removed from further consideration. Reduction is there- 
fore achieved in two different dimensions: the size of assumption sets and the 
number of FSSs. Steps 1-3 of algorithm Reduce (Figure 5) encode the reduction 
steps described in this section. The following section describes our technique for 
identifying erroneous program segments in each of the remaining FSSs. 



Projecting Assumptions to Focus- Statement Sequences Our technique 
is based on projecting the assumptions (left after discarding complementary 
constraints) on the corresponding FSS. We refer to the resulting subsequence as 
the Neighborhood of Error STatements (NEST), the region in the FSS where 
the user must apply corrective measures to remedy the corresponding counter- 
example (steps 5(a), (b) and (c) in Figure 5). 

Projection proceeds by forward analysis of the FSS. Each statement may 
or may not update the assumption set depending on whether or not it affects 
the constraints in the assumption set. Each statement is interpreted under the 
assumption set obtained after analyzing the statement preceding it in the FSS. 
The first statement is interpreted using the reduced assumption set of the FSS 
obtained by discarding complementary constraints in the assumption sets. 

The terminating condition (5(a)i in Figure 5) implies that we have identified 
the outermost conditional statement whose condition has generated unimportant 
constraints (discarded in the previous steps of the algorithm). Next, we mark 
the NEST as all of the focus statements that belong to the same block ^ as the 
conditional statement (error localization). Note that the size of the NEST can 
be significantly smaller than the actual program block in which it belongs as 
only the statements responsible for the assertion violation (i.e., the subsequence 
of the FSS) are included in the NEST. 

The NEST presents to the user a region which encompasses the error state- 
ment(s) present in the program (See figure 6). In the worst case (e.g., only one 

A block refers to all of the statements which are in the same or nested static scope. 
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FSS is generated due to the program error), the NEST encompasses the en- 
tire FSS, while in the best case, NEST identifies the exact statement which, if 
altered, will remove the program error. 

Analyzing the Median Identification Program. We illustrate the effec- 
tiveness of algorithm Reduce using the program given in Figure 7. This program 
sorts five integers al, a2, a3, a4, and a5, in only five comparisons given the par- 
tial order al>a2, a3>a4, al>a3. The Output of the program is a sorted list of 
output variables ol, o2, o3, o4, o5 in descending order. The program is based on 
the algorithm for finding the median of a list of numbers in linear time [8]. 

The program proceeds by considering inequalities between pairs of inputs. 
Consider first the two cases when a3>a5 [lines 9-40] and a3<a5 [lines 41-61]. In 
the former case, if a4>a5 is satisfied, the program proceeds to identify the correct 
position for a2 in the ordered list a3>a4>a5 [lines 12-24]. A similar technique is 
used for a4<a5 when the ordering is a3>a5>a4 [lines 26-38]. In the latter case, 
i.e., when a3<a5, the condition a2>a3 is used to find the correct position of a5 
with respect to the ordering al,a2,a3 [lines 42-50]; on the other hand, a2<a3 
implies that the sorted ordering is al, a5, a3, a2, a4 [lines 52-61]. 

Consider now an error in the program caused by an artificially injected in- 
correct conditional expression at line 14: a2 < a3 instead of a2 > a3. In this 
case we will get two FSSs, Fi = (4, 6, 9, 10, 11, 12, 13, 14, 15, 62, 63) with assump- 
tion set A\= {al > a2, a3 > a4, al > a3, a3 > a5, a4 > a5, a2 > a4, a2 > a3} 
and F 2 = (4,6,9,10,11,12,13,14,17,62,63) with assumption set ^2= (al > 
a2,a3 > a4, al > a3, a3 > a5, a4 > a5, a2 > a4, a2 < a3}. Step 2 of algorithm 
Reduce will delete the constraints a2 > a3, a2 < a3 from assumption sets A\ 
and A 2 , respectively. In steps 4 and 5 of the algorithm we project the modified 
set Al on F\ and modified set A 2 on F2. NEST is identified as (13, 14, 15) for Fi 
and (13, 14, 17) for F 2 . 

Introducing another bug at line 48 by copying line 46 to line 48 will generate 
three FSSs, two of which are the same as F\ and F 2 described above. The third 
FSS F3 comprises ((4,6,9,40,41,42,43,44,45,48,62,63)) and its corresponding 
assumption set A3 is |a3 < a5,a2 > a3, a5, > a2, a5 < al}. In this case, step 
2 of our algorithm will not delete the constraint a3 > a5 and a3 < a5 from 
any assumption sets as a3 > a5 exists both in Ai and A2. This will led us to 
identify NESTs (3, 14, 15) and (13, 14, 17) as in the previous case. This justifies 
the deletion of a constraint and its negation only if they exist in exactly two 
distinct FSSs. In the present case, there exists only one FSS (F3) that goes 
through the else-block of the condition at line 9. We cannot localize the error 
for F3 since step 5 of algorithm Reduce is iteratively executed until we reach the 
last statement in F3 and as such the entire F3 is marked as a NEST. 

3.3 Detecting Focus-Statement Sequence Modularly 
via Summarization 

Model checking involves finding whether an error state in the system is reachable 
from its start state. Efficient reachability analysis [11, 21] of programs with 
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1: int main(){ 

2: int al,a2,a3,a4,a5; 

3: int ol,o2,o3,o4,o5; 

4: int error=0; 

5: // input al, a2, a3, a4, 

6: if(!((al>a2)&&(a3>a4) 
&&(al>a3))){ 

7: exit(O); 

8: } 

9: if(a3 > a5){ 

10: ol^al; 

11: if(a4 > a5) 

12: if(a2 > a4){ 

13: o4=a4,o5=a5; 

14: if(a2 > a3) „ 

15: o2^a2,o3^^ 

16: else oq 

17: o2— a3,o3— 

18: }else{ 

19: o2=a3,o3=a4L2 

20: if(a2 > a5) ^ 

21: o4— a2,o5— 



else 

o4=a5,o5=a^ 



else /* line 11 *7' 
if(a2 > a5){ 

50: 
>1 = 
^ 1 : 
)2\ 
) 3 : 



o4=a5,o5=a4; 
if(a2 > a3) 
o2— a2,o3— a 

else 

o2=a3,o3=a 
}else{ 
o2=a3,o3=a5;^^ 
if(a2 > a4) 
o4= a2 , o5 = a^;,j, 
else |_o 

o4=a4,o5=a 

} 



} 

else 

if(a2 > a3){ 
o4=a3,o5=a4; 
if(a5 > a2){ 
o3=a2: 



V9-. 

60: 

61: 

62: 



63: 

64: 



if(a5 > al) 
ol=a5,o2=al; 
else 

ol=al,o2=a5; 

}else 

al,o2=a2,o3=a5; 

}else{ 
o3— a3; 
if(al > a5) 
ol=al,o2=a5; 
else 

ol=a5,o2=al; 
if(a2 > a4) 

o4=a2,o5=a4; 

else 

o4=a4,o5=a2; 

} 

if((ol<o2)||(o2<o3)|| 

(o3<o4)||(o4<o5)){ 

error=l; 

} 



Fig. 7. Sorting five partially ordered numbers 



recursions employs summarization of procedures with respect to the valuation 
of global variables. Intuitively, summarization represents the effect of a procedure 
and involves computing the relation between variable valuations at its start and 
exit points. The main advantage of this technique is modularity and efficiency; 
each procedure is analyzed in isolation and their summaries are used for forward 
reachability analysis. Observe that program behavior is classified using three 
types of transitions: 



Statement Transition 

return: s , g ► e, g' 

call: s, g ► 91 : ^2, 92 



other; s, g ► s' , g 



Stack depth Global variable valuations 

decreases by 1 g and g' respectively before and after executing s 

increases by 1 9i 9i i 92 call statement s of callee, 

start statement of the called procedure and 
return location S 2 of the callee respectively 
no change g and g respectively before and after executing s 



Based on the above observations, the effect of a procedure on the global variables 
is the least fixed point of relation fsum( 5 , s,g'), where s is the start state of the 
procedure and g and g' are the valuations of global variables at the entry and 
exit point of the procedure, respectively. It can be shown that the procedure 
with m transitions can be summarized in time 0{m x g^) [II]. 



fsum(g, s, g') 4= s,g >e,g' 

fsum(g, s, g') 4= s,g >si,gi:S 2 ,g 2 A f sum(gi , si , g 2 ) A f smn(g 2 , S 2 , g') 

fsum(g, s, g') 4= s,g >si,giA f sum(gi , si , g') 

To find a sequence of statements leading to violating state our FocusCheck 
model checker performs forward reachability analysis from the start state of the 
program. Each call site in the program is interpreted in terms of the effect of the 
called procedure on the global variables. In other words, if there are multiple calls 
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(say k) to the same procedure, the called procedure is analyzed once to compute 
the f sum relation instead of analyzing it k times. Summarization, therefore, makes 
a significant contribution to the efficiency of model checker. 

Summarizing Effects of Procedures Using Backward Reachability. 

Focus statements are identified by backward reachability analysis of counter- 
examples (Section 2). The technique involves dynamically computing a set Error 
consisting of variables whose valuations directly or indirectly affect the variable 
valuation that caused assertion violation. As in forward reachability analysis, 
backward reachability is also performed efficiently using summarization of pro- 
cedures. Given the set Error and the valuations of global variables at the exit 
point of a procedure, summarization involves computing the Error set, the valu- 
ation of global variables at the start location of the procedure, and the sequences 
of focus statements. The summary of a procedure computed via backward analy- 
sis is defined by the least model of the bsum(g, e, fss, s, g\ e', fss') relation, where 
(a) s is the start location of the procedure, (b) g',e',fss' are the valuation of 
the global variables, the Error set, and the sequence of focus statements at the 
exit point of the procedure and (c) g, e, fss are the valuation of global variables, 
the Error set, and sequence of focus statements at the entry point. 

bsum(5, e,fss,s,5^,e^,fss’) s, g > e, g' A update(e, fss,s,e^,fss’) 

bsum(5, e, fss, s, g' , e' ,fss*) s, g > si, gi : S2, g2 A hs\m{g2 , 62, iss2, S2, g' ■, e' , fss’) A 

bs'mn(pi , ei , fssi , si, g2, e2,iss2) A update(e, fss,s,ei,fssi) 

bsum(p, e,fss,s,5^,e^,fss’) ■<= s, g >■ si, g± A bs'mn(pi ,ei,fssi,si,5',e^,fss’) A 

update (e, fss,s,e',fss’) 

update(e, f ss, s, e', f ss') checks whether the statement s affects the Error set 
(e'). fss' is the FSS identified up to the point statement s is visited in backward 
reachability analysis. In the event s is classified as a focus statement, fss is 
generated by pre-pending s to fss' while e' is appropriately updated to e. 

The distinguishing feature between fsum and bsum relations, used for sum- 
marizing procedures during forward and backward reachability analysis respec- 
tively, is the order in which the transition between statements appearing in the 
execution sequence is analyzed. Consider the second rule in the definition of the 
relations fsum and bsum, the case where s corresponds to a call statement. The 
fsum relation proceeds by computing the fsum of the called procedure followed by 
the fsum of the callee starting from the return location. On the other hand, bsum 
first computes the bsum of the callee starting from the return location followed 
by the bsum of the called procedure. 

However, the common aspect of fsum and bsum is that summarization makes 
forward and backward analysis of program traces efficient. Both relations once 
computed for each procedure are used multiple times if the same procedure is 
invoked multiple times in a program with the same input/output parameters 
(global valuations. Error sets, focus statements). To illustrate the impact of the 
bsum relation in finding FSSs, consider the following example. Assume proce- 
dure Q is invoked k times in the error trace in procedure P, and Q has m 
different paths from its start to exit point. Further assume that Q does not af- 
fect the counter-example sequence and as such does not contribute to set Error. 
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Fig. 8. (a) Architecture of the FocusCheck model checker, (b) Call graph for RA 

module 



That is, statements in Q do not appear in the FSS. Naive backward reachability 
analysis from the error state will analyze Q by inlining the procedure at its call 
sites; i.e., the m different paths in Q will be analyzed k times. On the other 
hand, summarization will analyze the m different paths in Q only once and use 
the summary result at each of the call sites. 

4 Tool Description 

In this section, we describe the salient features of our FocusCheck model checker 
FocusCheck, in which we have implemented the techniques described in this pa- 
per. 

Input Language Description. The FocusCheck model checker takes as input 
programs written in Cimple, an expressive subset of C. The basic building blocks 
of Cimple are integer, boolean and array data types, and assignment, conditional 
(if, while statements), call and return statements. Due to the absence of point- 
ers and address reference mechanisms, array of size n is treated as n different 
variables identified by the name of the array appended to the index value of the 
element; e.g. the third element in an array arr is identified by the variable arr3. 
Calls to procedure are treated as call-by-value and returns from procedure are 
explicitly handled by assigning the return value to a pre-specified global variable. 

Reachability Analyzer. The input to the reachability analyzer is a Cimple 
program and one or more error conditions. Forward reachability searches for all 
counter-examples in the program, and records the control and data dependencies 
at each statement present in the search path. Backward reachability analysis of 
counter-examples identifies the FSSs using dependency information. Operations 
of FSSs are checked for feasibility using CLP(R), a built-in constraint solver in 
the XSB tabled logic-programming environment [26]. The primary advantage 
of using logic programming to implement the reachability analyzer includes the 
direct implementation of least fixed-point summarization relations f sum and bsum. 
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Error Conditions 


Assumptions 


Simple 

Reachability 

(sec) 


Reachability by 
Summarizing 
(sec) 


altSep=UPWARD_RA 


otherTr ackedAlt > ownTr ackedAlt 
upSeparation>downSeparation 
downSeparation<positiveRAAltThresh 


8.76 


4.23 


altSep=DOWNWARD_RA 


ownTrackedAlt> OtherTr ackedAlt 
upSeparation<downSeparation 
upSeparation>positiveRAAltThresh 


7.44 


3.98 



Fig. 9. Results of model checking the RA module 



The output of the reachability analyzer is a set of focus-statement sequences 
along with their assumption sets. 



Components for Post-processing FSSs. Ranker orders FSS-assumption 
pairs and presents the ordered list to the user (Section 3.1). The user can also 
provide a subset of input variables that s/he considers as important and Projec- 
tor identifies the constraints over these variables from the assumptions of each 
FSS. Finally, the Error Neighborhood Detector (END) employs the technique 
described in Section 3.2 to localize errors to specific segments in each FSS. 

5 Verification of the TCAS Resolution Advisory Module 

The Trajfic Alert and Collision Avoidance System (TCAS) [23] issues commer- 
cial airline pilots traffic advisories when one or more aircrafts comes in close 
proximity (airspace) of the controlled aircraft. We concentrate here on the Res- 
olution Advisory (RA) module of TCAS which is used to identify the safest 
maneuver for the controlled aircraft in the context of various parameters: rel- 
ative position of the intruder aircraft, motion trajectory, minimum protected 
zone for the controlled aircraft, etc. The RA module sets a variable altsep to 
UPWARD_RA or DOWNWARD_RA depending on whether the preferred safety action of 
the controlled aircraft is to move to a higher or lower altitude. 

We analyzed the RA module (174 lines of C source code^ [15]) using our 
FocusCheck model checker, using different valuations of altsep as error condi- 
tions. The objective was to identify various preconditions on input variables 
necessary for specific valuation of altsep. The assumptions generated exactly 
match the preconditions and prove the correct behavior of the RA module (Ta- 
ble 9). Another important aspect of the RA module is its control structure 
(Figure 8(b)): a number of procedures are invoked multiple times from different 
procedures. Timing results reveal that reachability analysis using summarization 
outperforms naive reachability analysis based on inlining. 

® Implementation of RA module only uses the C language constructs that can be 
handled by FocusCheck model checker and as such we are not required to perform 
any abstraction or transformation of the source code. 
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6 Related Work 

A number of techniques have recently been proposed to provide users with 
minimal information required to explain counter-examples resulting from model 
checking. In [25], the authors introduce the notion of neighborhood of counter- 
examples which can be used to understand the cause of counter-examples. A dif- 
ferent approach based on game-theoretic techniques is put forth in [20] where 
counter-examples are augmented into free segments (choices) and fated segments 
(unavoidable). Errors are most likely to be removed by careful selection of free 
segments. 

In [I], errors in programs are localized by identifying the diverging point be- 
tween a counter-example and a positive example; a positive example is a sequence 
of statements in programs that does not lead to a violation of the property of 
interest. A similar approach is presented in [14] where errors are localized to 
program statements absent in all positive examples and present in all counter- 
examples leading to the same error condition. Based on the idea of detecting the 
divergence as the cause of the counter-example, [13] has developed a technique 
that uses a distance matrix and constraint manipulations to pin-point the vari- 
able operations that led to the divergence. The technique, however, is applied 
to one counter-example in the program. In contrast, we present a hierarchy of 
error explanations by analyzing multiple counter-examples. 

7 Conclusion 

We have presented a methodology for helping users locate and debug program 
errors. The essence of our approach is to present the user with an ordered set 
of focus-statement sequences, obtained by variable dependency analysis of all 
counter-examples present in a program written in the Cimple programming lan- 
guage. 

As future work, we intend to enrich the Cimple language with pointer con- 
structs and dynamic memory allocation, and concomitantly apply subset-based, 
interprocedural, flow-sensitive pointer-analysis techniques. The FocusCheck 
model checker will be appropriately enhanced to handle these new constructs. 
We would also like to apply our approach to large code bases in order to under- 
stand various scalability issues. One approach we plan to pursue utilizes partial 
code coverage. Finally, extending our techniques to concurrent programs in or- 
der to verify temporal safety and liveness properties is another avenue of future 
research. 
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Abstract. We describe a semi-automated verification of a slightly opti- 
mised version of Michael and Scott’s lock-free FIFO queue implementa- 
tion. We verify the algorithm with a simulation proof consisting of two 
stages: a forward simulation from an automaton modelling the algorithm 
to an intermediate automaton, and a backward simulation from the in- 
termediate automaton to an automaton that models the behaviour of 
a FIFO queue. These automata are encoded in the input language of the 
PVS proof system, and the properties needed to show that the algorithm 
implements the specification are proved using PVS’s theorem prover. 



1 Introduction 

Performance and software engineering problems resulting from the use of locks 
have motivated researchers to develop lock-free algorithms to implement con- 
current data structures. However, these algorithms are significantly more com- 
plicated than lock-based algorithms, and thus require careful proofs to ensure 
their correctness. Such proofs typically involve long and tedious case analyses, 
with few interesting cases. Thus, it is desirable to have a tool that generates and 
checks all the cases, requiring human guidance only in the few interesting cases. 

In this paper, we discuss the verification of a lock-free queue algorithm based 
on the practical and widely used algorithm of Michael and Scott [ I ] . which to our 
knowledge has not been formally verified before. We prove that the algorithm is 
linearisahle [2], using a simulation proof, which involves constructing a special 
kind of relation, called a simulation, between the states of two automata mod- 
elling the algorithm and its specification. We use the PVS verification system [3] 
to check the proof. 

Our verification has three principal points of interest: First, unlike many 
practical algorithms, which can be verified using only a forward simulation, this 
algorithm also requires a backward simulation, which is trickier to verify. Second, 
the way in which we model a dynamic heap, and use an existentially quantified 
function to relate objects in the heap with abstract data, avoids many difficulties 
associated with reasoning about dynamic data structures. Third, we developed 
various techniques to help PVS automatically dispose of most of the cases in the 
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Head Tail Head Tail 




Fig. 1. Basic queue representation 



structure pointer_t {ptr\ pointer to node_t, ver: unsigned integer} 
structure node_t {value: data type, next: pointer_t} 
structure queue_t {Head: pointer_t, Tail: pointer_t} 

Initialise(Q: pointer to queue_t) 

node = new_node(); node— >next.ptr = null; 

Q^Head — Q—>Tail = [node, 0]; 

Fig. 2. Global declarations and initialisation 



simulation proofs. Using these techniques, we encountered few cases in which we 
needed to provide guidance to the prover. 

We present the queue algorithm in Sect. 2. In Sect. 3, we introduce I/O 
automata and show how to model the queue specification and implementation. 
Sect. 4 describes our verification. Sect. 5 discusses our experience using PVS. 
We conclude in Sect. 6. 

2 The Queue Implementation 

Our algorithm implements a queue as a linked list of nodes, each having a value 
and a next field, along with Head and Tail pointers. Head points to the first node 
in the list, which is a dummy node; the remaining nodes contain the values in 
the queue. In quiescent states (i.e., when no operation is in progress). Tail points 
to the last node in the list. Fig. 1 shows an empty queue and a queue contain- 
ing values a, b and c. The declarations and initialisation are shown in Fig. 2. 
Pseudocode for the Enqueue and Dequeue operations is given in Fig. 3. 

Shared locations containing pointers (i.e.. Head, Tail and next) are updated 
using compare- and- swap (CAS) operations.^ CAS takes the address of a memory 
location, an “expected” value, and a “new” value. If the location contains the 
expected value, the CAS succeeds, atomically storing the new value into the 
location and returning true. Otherwise, the CAS fails, returning false and leaving 
the memory unchanged. 

These shared locations also contain a version number, which is incremented 
atomically every time the location is written.^ Thus, if such a location contains 

^ The one exception is in the initialisation of a new node (line E3), where a store is 
sufficient because no other process can access a node while it is being initialised. 

^ In this paper, we treat version numbers as unbounded naturals, so they never “wrap 
around”. This simplification is reasonable as long as enough bits are used for the 
version number [4]. 
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Enqueue(Q: pointer to queue_t, 
value: data type) 

El: node — new^nodeQ 
E2: node — rvalue— value 
E3: node — >^next.ptr — null 
E4: loop 

E5: tail — Q — >Tail 

E6: next — tail.ptr — *next 

E7: if tail — — Q— s-TaiJ 

E8: if next.ptr —— null 

E9: if CAS(&taiJ.ptr— s-uext, next, 

[node, next.ver+1]) 
ElO: break 

Ell: endif 

E12: else 

E13: CAS(&Q^Tai], tail, 

[next.ptr, taii.ver+1]) 

E14: endif 

E15: endif 

E16: endloop 

E17:CAS(&Q^Tai], tail, 

[node, taii.ver+1]) 



Dequeue(Q: pointer to queue_t, 

pvalue: pointer to data type): boolean 

Dl: loop 

D2: head — Q — >^Head 

D3: next — head — >next 

D4: if head Q — ^Head 

D5: if next.ptr —— null 

D6: return false 

D7: else 

D8: Upvalue — next.ptr — >^vaiue 

D9: if CAS(&Q^ffead, head, 

[next.ptr, head. ver+lj) 

DIO: tail — Q — ^Taih, 

Dll: if (head.ptr — — taiJ.ptr) 

D12: CAS(&Q^Taii, tail, 

[next.ptr, taii. ver+lj); 

endif 

break 

D13: endif 

D14: endif 

D15: endif 

D16: endloop 
D17: free^node (head.ptr) 

D18: return true 



Fig. 3. Queue operations 



Head Tail Head Tail 




Fig. 4. Queue representation variations 



the same value at two different times, then the location had that value during 
the entire interval. 

A process p executing an Enqueue operation acquires and initialises a new 
node (E1-E3), and appends the new node to the list by repeatedly determining 
the last node in the list, i.e., the node whose next.ptr field is null (E5-E8, E13), 
and attempting to make its next.ptr field point to the new node (E9). Then p 
attempts to make Tail point to this node (E17).^ Between p appending its new 
node and Tail being updated. Tail lags behind the last node in the list (see 
Fig. 4). 

We cannot determine the last node in the list by just reading Tail, because 
another enqueuing process q may cause Tail to lag. Since p cannot wait for q to 
update Tail, p attempts to “help” q by doing the update (E13). Thus, Tail can 
lag behind the end of the list by at most one node. 

Also, another process may change Tail after p reads it at E5, but before p 
dereferences (its local copy of) the pointer at E6. To ensure that the value read 
at E6 is valid, p checks at E7 that Tail has not changed since p executed E5. If 
the test at E8 shows that the node accessed at E6 had no successor at that time, 

® The CAS at E17 can be deleted without affecting the correctness of the algorithm. 
However, without this CAS, Tail would not point to the last node of the list in all 
quiescent states. 
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then we know that the node was the last node in the list at that time. Similarly, 
a successful CAS at E9 guarantees that the next field of that node is unchanged 
in the interval between p’s executions of E6 and E9. 

A process p executing a Dequeue operation checks whether the dummy node 
has a successor (D2-D5). If not, then the queue was empty when p executed D3, 
so the operation returns false (D6). As in the Enqueue operation. Head is read 
twice to ensure that the node accessed at D3 was the dummy node at that time. 

If the dummy node has a successor, then p reads the value in the successor 
node (D8), expecting that this node is the first non-dummy node in the list. 
Then p attempts to swing Head to point to the node whose value p read at D8 
(D9). If the attempt succeeds, that node is the new dummy node; its value is 
removed from the queue by the successful CAS. If the attempt fails, p retries 
the operation from the beginning. 

Once p has successfully executed the CAS at D9, it remains to allow the 
old dummy node to be reused. This node cannot be freed to the system because 
another process may be about to access it; instead, it is placed on a freelist, using 
the freejnode operation (D17). The new-node operation (El) returns a node from 
the freelist, if one is available; otherwise, it allocates and returns a new node. 

Before passing the old dummy node to free-node, a dequeuing process checks 
for the special case shown in Fig. 4(b), where the Head and Tail have “crossed”, 
because Tail points to the old dummy node (DlO-Dll). In this case, it attempts 
to update Tail (D12) before putting the old dummy node on the freelist. 

Our algorithm differs from Michael and Scott’s [1] in that we test whether 
Tail points to the dummy node only after Head has been updated, so a de- 
queuing process reads Tail only once. The Dequeue in [I] performs this test 
before checking whether the next pointer in the dummy node is null, so it reads 
Tail every time a dequeuing process loops. Under high load, when operations 
retry frequently, this change will reduce the number of accesses to shared mem- 
ory. 

3 Modelling the Queue Specification and Implementation 

This section briefly introduces the input/output automaton (lOA) formalism [5], 
and shows how we use 10 As to model the queue specification and implementa- 
tion. 

An input/output automaton is a labelled transition system, along with a sig- 
nature partitioning its actions into external and internal actions. Formally, an 
lOA consists of: a set states{A) of states; a nonempty set start{A) C states{A) 
of start states; a set acts{A) of actions; a signature, sig{A) = {external{A) , 
internal{A)) , which partitions acts{A); and a transition relation, trans(A) C 
states{A) x acts{A) x states{A)A 

We describe the states by a collection of state variables, and the transition 
relation by specifying a precondition and effect for each action. A precondition 

The definition in [5] includes additional structure to support fairness and composi- 
tion, which we do not require for this work. 
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is a predicate on states, and an effect is a set of assignments showing only 
those state variables that change, to be performed as a single atomic action. 
For states s and s' and action a with precondition prca and effect effa, the 
transition (s,a,s') is in trans{A), written s — > s', if and only if prca holds 
in s (the pre-state) and s' (the post-state) is the result of applying effa to s. 
We say that an action a is enabled in s if prea holds in s. These descriptions 
are parameterised by process and sometimes by other values, so they actually 
describe sets of transitions. 

A (finite) execution fragment of A is a sequence of alternating states and 
actions of A, tt = sq, ai, si, . . . Sn, such that {sk-i, ak, Sk) G trans(A) for k G 
[1, n]. An execution is an execution fragment with sq G start{A)? A trace is the 
sequence of external actions in some execution. We say that two executions (not 
necessarily of the same automaton) are equivalent if they have the same trace, 
and we write traces (A) for the set of all traces of A. We also write trace{a) 
to denote the sequence of external actions in a sequence a G acts (A)*, where 
acts{A)* is the set of finite sequences over acts{A). For a G acts{A)*, we write 
s — ^ s' to mean that there is an execution fragment beginning with s, ending 
with s', and containing exactly the actions of a. 

I/O automata can be use to model both specifications and implementations; 
in both cases, the set of traces represents the possible external behaviours of 
the automaton. For an “abstract” automaton A, modelling a specification, and 
a “concrete” automaton C, modelling an implementation, we say that C imple- 
ments A if traces{C) C traces{A), that is, if all behaviours of the implementation 
are allowed by the specification. 

3.1 The Abstract Automaton 

The standard correctness condition for shared data structures is linearisabil- 
ity [2], which requires that every operation appears to take effect atomically 
at some point between its invocation and its response; this point is called the 
operation’s linearisation point. We specify the acceptable behaviours for a set 
of concurrent processes operating on a shared queue, by defining an abstract 
automaton AbsAut which generates their linearizable traces. The transition re- 
lation for AbsAut is defined in Fig. 5. 

AbsAut has external actions enqAnVp(v) and deqAnVp, representing opera- 
tion invocations, and enq_respp, representing the response from an Enqueue, 
for all processes p and values v. For simplicity, we assume that queue values are 
pointers, and model Dequeue as always returning a pointer, which is null when 
the queue is empty. Thus, AbsAut has external actions deq_respp(r), where p 
is any process and r is any value (i.e., non-null pointer) or null. AbsAut also 
has internal actions do-enqp and do-deq^, for all processes p, representing the 
operations’ linearisation points. 

® The full theory of I/O automata also allows infinite executions, which are necessary 
to reason about liveness, which we do not consider in this paper. 
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enqjnvp(v): 
pre: pc^ = idle 
eff: pcp := enq{v) 



do_enq^: 

pre: pcp = enq{v) 
eff: pCp := enq_resp 



enq_resp\ 

pre: pcp = enq_resp 
eff: pCp := idle 



Q ■- enq{Q, v) 



deqJnVp : 
pre: pcp = idle 
eff: pCp ~ deq 



do_deqp : 
pre: pcp = deq 



deq-respp{r): 

pre: pcp = deq_resp{r) 



eff: pCp ~ deq_resp{deq(Q).v) eff: pCp := idle 
Q ■— deq(Q).q 



Fig. 5. Abstract transitions for process p; v may be any value, and r may be any 
value or null 

Each process p has a “program counter” pCp that controls the order in which 
actions can occur by determining which actions are enabled, and sometimes 
also encodes the value being enqueued or dequeued. For example, when p is 
not in the midst of any operation, pCp = idle, so enq_inVp(v) and deq_inVp are 
both enabled; if an enq_inVp(v) action occurs, pCp is set to enq(v), so then only 
do-enqp is enabled. 

AbsAut has a global variable Q, which holds the abstract queue. The abstract 
queue is modelled as a function seq from naturals to values, along with Head and 
Tail counters that delimit the range corresponding to queue elements. The queue 
consists of seq{Head+l) through seq(Tail), inclusive; it is empty if Head = Tail. 
The effects of do-enqp and do-deqp actions are defined in terms of functions 
enq and deq: enq{Q, v) returns the queue obtained by incrementing Q.Tail and 
placing V at the new Tail index. When Q is not empty, deq{Q) returns a pair 
{deq{Q).q, deq{Q).v) consisting of the queue obtained by incrementing Q.Head 
and the element at the new Head index. When Q is empty, deq{Q) = {Q, null). 

Each process repeatedly performs either an Enqueue or Dequeue opera- 
tion, and each such operation consists of an invocation, a single internal action 
that atomically updates the abstract queue, and a response. Thus, the trace 
of any execution of AbsAut is consistent with a set of processes operating on 
a linearisable queue. 

3.2 The Concrete Automaton 

The concrete automaton ConcAut models the queue implementation described 
in Sect. 2. ConeAut has the same external actions as AbsAut, and has one internal 
action for each line of code shown in Fig. 3 that contains a read or a write, and 
two internal actions for each line of code containing a conditional or a CAS. For 
example, action e_Jp models a process p executing line El of Enqueue, and 
d_4_yeSp and d-4_nOp model p executing D4 when the condition evaluates to 
true and false, respectively. 

Each process p has a “program counter” pCp, ranging over a type that con- 
tains one value for each line of code containing a read, write, conditional or 
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CAS, and special values idle, enq_resp and deq^resp that play the same roles as 
in AhsAut. 

We model a heap in which every object is a node with two fields value and 
next, each of which contains a pointer/ version- number pair, whose components 
are denoted by pair.ptr and pair.ver. We write V for the set of pointers, Ti. for 
the set of heaps, and T for the set of field names (either value or next). A heap 
h G Ti. is a pair (h.eval, h.unalloc): the function h.evahV x IF ^ 7^ x N takes 
a pointer to a node and a field, and returns the pointer value and version number 
associated with that field of that node in h; and h.unalloc is the set of pointers 
that are not allocated in h. Generalising this model to allow multiple object 
types is straightforward, but this simple model suffices for our purposes. 

ConcAut has variables h G Ti., Head, Tail G V x N, and freelist C V, which 
model the heap. Head, Tail and the freelist. For each process p, there are variables 
headp, tailp, nextp G V x N, and nodep G V, which model the local variables in 
the code, and a local variable resultp G V to hold the value that p returns from 
Dequeue. 

An assignment pt^fd := [pf , i), which updates field fd in the node pointed 
to by pt, is modelled using a function update: HxVxiFxVxN^H defined 
by:® 



update{h , pt , fd , pt' , i) = {h.eval (B {{pt,fd) i— > (pt' ,i)}, h.unalloc) 

Allocation of a new node is modelled with the function new: Ti. ^ Ti. x V 
satisfying the following properties:^ 

new{h) = (h' , null) h.unalloc = 0 A h' = h 
new{h) = (h' ,p) A p ^ null 

p G h.unalloc A h' .eval = h.eval A h' .unalloc = h.unalloc \ {p} 

The preconditions and effects of some representative actions of the concrete 
automaton are shown in Fig. 6. Transitions for the other actions are defined 
similarly. 

In subsequent sections, we write pt^fd for cs.h.eval{pt,fd), and cs .free! (pt) 
for pt G cs. unalloc U cs. freelist, where cs is a state of ConcAut. 

4 Verification 

To verify our queue implementation, we use a simulation proof [6], which shows 
how to construct, from any execution of the concrete automaton, an equivalent 
execution of the abstract automaton, proving that ConcAut implements AbsAut. 

Simulation proofs can often be done using a forward simulation (see Fig. 7), 
in which the abstract execution is constructed by starting at the beginning of 

® / © {s I— > 2/} yields a function /' such that f'{x) = y and f'{z) = f{z), for z x. 

^ Michael and Scott do not specify what happens if Enqueue is unable to allocate 
a new node. In our model, if new returns a null pointer, ConcAut loops until space 
becomes available. A practical implementation would trap this error. 
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G—3p . 

pre: pcp = e_3 

eff: nodep^next.ptr := null 
pCp ~ e_5 

d-2p: 

pre: pcp = d_2 
eff: headp := Head 
pCp := d_3 



e_9_yeSp: 

pre: pcp = e_9 A nextp = tailp.ptr—>next 
eff: tailp .ptr—mext := {nodep , nextp .ver + 1 ) 
pCp ~ e_17 

e_9_nOp : 

pre: pcp = e_9 A nextp 7 ^ tailp. ptr^ next 
eff: pCp := e_5 



Fig. 6. Part of the transition relation of ConcAut 



the concrete execution and working forwards. However, forward simulation is 
not sufficient to prove that ConcAut implements AbsAut. The only point during 
a Dequeue operation at which the queue is guaranteed to be empty is when the 
operation executes D3, loading null into next. A forward simulation would need 
to determine at this point whether the operation will return null. This is not 
possible, however, since the operation will retry if Head is changed between the 
operation’s execution of D2 and D4. Therefore, we need to use a backward sim- 
ulation (see Fig. 8), showing how to construct an abstract execution by working 
from the last step of a concrete execution back to the beginning. 

Since only this one aspect requires backward simulation, we define an inter- 
mediate automaton IntAut, which captures the behaviour of the implementation 
that defies forward simulation, namely the handling of Dequeue on an empty 
queue, and is otherwise identical to AbsAut. We then prove a backward sim- 
ulation from IntAut to AbsAut (see Sect. 4.2), and a forward simulation from 
ConcAut to IntAut (see Sect. 4.3). 

4.1 The Intermediate Automaton 

The intermediate automaton IntAut is identical to the abstract automaton, ex- 
cept that in IntAut, a process executing a Dequeue operation may “observe” 
whether or not the queue is empty at any time before it decides what value to 
return. In addition to the queue and counter variables that are in AbsAut, each 
state of IntAut has a variable empty_okp, to record whether p has observed an 
empty queue during the current Dequeue operation. 

IntAuthas the same external actions as AbsAut, and the same internal action 
do-enqp ; the only difference for these transitions is that deqAnVp sets empty-okp 
to false. IntAut has a new internal action observe-emptyp that sets empty-okp 
to record whether or not the queue Q is empty, which p may perform whenever 
its program counter value is deq. Also, in place of the do-depp action in AbsAut, 
IntAut has two actions, deq^emptyp and deq-nonemptyp, allowing these cases 
to be treated separately. The deq-nonemptyp action is the same as the abstract 
automaton’s do-depp action except that its precondition additionally requires 
that the queue is nonempty. The deq^emptyp action simply changes p’s program 
counter from deq to deq-resp(null). The precondition for this action requires that 



Formal Verification of a Practical Lock-Free Queue Algorithm 105 



(V cso • (3 aso • R(cs, as))) (1) 

(V cs, cs' , as, a • 

R{cs, as) A cs — ^ cs' => 

(3 as' , b • 

R{cs' , as') A as — ^ as' A 
trace{a) = trace(b))) (2) 



Fig. 7. A relation R C states{C) x 
states{A) is a forward simulation from C 
to A if C and A have the same ex- 
ternal actions and these conditions 
hold, where csq. start[C) , aso'- start{A) 
cs, cs': states{C), as, as': states{A), 

a: acts{C), b: acts{C) 



(V cs • (3 os • R{cs, as))) (3) 

(V csq: start{C), as • R{cs, as) 

as e start(A)) (4) 

(V cs, cs' , as' , a • 

R{cs' , as') A cs — ^ cs' => 

(3 as, b • 

(cs, as) A as — ^ as' A 
trace{a) = trace{b))) (5) 

Fig. 8. A relation R C states {C) x 
states {A) is a forward simulation from C 
to A if C and A have the same external 
actions and these conditions hold 



empty_okp is true, indicating that p has observed that the queue was empty at 
some point during its execution; the Dequeue operation is linearised to one 
such point. 

Splitting Dequeue operations that return null into one or more observations 
that the queue is empty, followed by a decision to return null based on the 
knowledge that we have observed the queue to be empty at some point during 
the operation, makes it possible to prove a forward simulation from the concrete 
automaton to the intermediate one, as we show in Sect. 4.3. 

It is easy to see that IntAut captures the behaviour of a set of processes 
accessing a linearisable FIFO queue; we describe a formal proof in the following 
section. 

4.2 Backward Simulation Proof 

In this section we define a relation BSR (see Fig. 9), and show that it is a back- 
ward simulation from IntAut to AbsAut. Given states as of AbsAut and is of 
IntAut, the third conjunct of BSR requires that the queues represented by the 
two states are the same. The first two conjuncts require that each process is 
roughly speaking “at the same stage” of the same operation in both states, or is 
not executing any operation in either state. For example, if p is idle in is (i.e., 
is.pCp = idle) then p is also idle in as. The first conjunct (basic-ok) covers the 
simple cases; the second conjunct {dequeuer_ok) covers the only interesting case, 
in which a process can be at slightly different stages in the two automata because 
Dequeue operations can take two or more steps. Specifically, if in is, p has in- 
voked Dequeue but has not yet executed either deq-emptyp or deq-nonemptyp 
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def 

BSR{as, is) = basic-ok{as, is) A dequeuer_ok{as , is) A is.Q — as.Q 
basic_ok[is, as) '^= 

Vp • is.pCp 7^ deq => is.pcp = as.pCp 
dequeuer_ok{as , is) '^= 

Vp • is.pCp = deq^ {as.pCp = rfeg V (as.pCp = deq_resp{nuU) A is. empty _okp)) 
Fig. 9. The backward simulation relation BSR 



(i.e., is.pCp = deq), then in as, either pcp is also deq, or pep = deq-resp{nult) , indi- 
cating that p has already executed deq-emptyp. In the latter case, is .empty-okp 
must also be true, showing that p has observed that the queue was empty at 
some point during its Dequeue operation. 

Conditions (3) and (4) of Fig. 8 are trivial, because related states of AbsAut 
and IntAutare almost identical. Condition (5) requires that, for every transition 
is — ^ is' of IntAut, if BSR{is' , as') holds, then there is some abstract state as 
and some sequence b of abstract actions, containing exactly the same external 
actions as a, such that executing each action b, starting from as, takes the 
abstract automaton into state as' . 

To aid in the automation of our proof, we define a function that calculates as 
given is, is', as' and a. Similarly, we define a step- correspondence function [7], 
that determines the action sequence to choose for the abstract automaton given 
an action of the intermediate automaton (in our proof, this sequence always 
consists of either zero or one action) . Specifying these functions allows us to avoid 
manually instantiating the existentially quantified abstract state and abstract 
action required by the proof obligation: instead we simply use the two functions 
to calculate them directly. 

These functions are defined as follows. For every intermediate action a except 
observe-empty, deq^empty and deq-nonempty, we choose the same action a for 
AbsAut, for deq-nonempty, we choose do-deq; and for deq-empty, we choose the 
empty action sequence. Recall that a Dequeue operation on an empty queue 
is linearised to a point at which it executes observe-empty, and not when it 
executes deq-empty. We reflect this choice of linearisation point by choosing 
do-deq for exactly one execution of observe-empty within that operation. 

Given the abstract action chosen for a particular intermediate transition, it is 
generally easy to construct a pre-state as from the post-state as' . In many cases, 
we simply replace the program counter of the process p whose action is being 
executed in the intermediate transition with the value required by the precondi- 
tion of the abstract action. The only nontrivial case arises for the do-enq action, 
because to construct the program counter before the action, we must determine 
what value the Enqueue operation is enqueuing. This is achieved by taking the 
value from the queue position that is updated by the do-enq action. 

Having chosen an abstract action b, it is usually straightforward to prove 
as — ^ as' , since the construction of as ensures that the precondition for b holds 
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and applying the effect of b to as yields as'. It is slightly trickier in one case, 
where the intermediate transition is an observe-empty action. Not every execu- 
tion of observe-empty corresponds to a linearisation point for a Dequeue oper- 
ation that returns null {IntAut can execute observe-empty multiple times within 
a single Dequeue operation, while in AbsAut there is exactly one do_deq action 
per Dequeue operation). Therefore, for each Dequeue operation that returns 
null, we must choose do_deq for exactly one occurrence of observe-empty, and 
choose the empty action sequence for the others. 

We can only linearise a Dequeue operation by process p to an execution 
of the observe-emptyp action if the Dequeue operation returns null. This is 
true if pCp in as' is deqjresp{null), in which case we can infer that empty_okp in 
is' is true, from the dequeuer_ok conjunct of BSR. Because observe-emptyp sets 
empty_okp to true if and only if the queue is empty in state is, and does not 
modify the queue, it follows that the queue is empty in state is' , and therefore by 
BSR, the queue is empty in state as' . Therefore, we can construct the state as 

do-deq^ 

with an empty queue, which is needed to show that as — > as is a transition 
of the abstract automaton. Thus, we show that we can choose do-deq^ when a 
is observe-emptyp and as' .pCp is deq-resp{null) . In all other cases, we choose the 
empty sequence for the abstract automaton when a is observe-emptyp . It is easy 
to see that BSR{is, as') holds in these cases because the only possible difference 
between states is and is' is that empty_okp is true; the value of this variable 
affects the truth of BSR{is, as') only if pCp in as' is deq-resp{null) . 

4.3 Forward Simulation Proof 

In this section we describe a relation FSR, which is a forward simulation from 
ConcAut to IntAut. Because the concrete and intermediate automata are very 
different, the simulation relation and the proof are both substantially more com- 
plicated than the relation and proof described in Sect. 4.2. We do not have 
space here to describe the whole simulation relation or the whole proof; instead 
we present a detailed overview of the most interesting parts. 

The forward simulation relation over intermediate state is and concrete state 
cs is 

FSR{cs,is) 3/: reZ(js, cs,/) 

where / is a function from naturals to pointers called the representation function; 
we explain the purpose of / below. Fig. 10 defines rel. Fig. 11 defines obj-ok, and 
Fig. 12 defines some of the other predicates used in defining rel. 

The most important part of reZis the predicate obj_ok, which expresses the re- 
lationship between the concrete data structure, represented by nodes and point- 
ers in ConcAut, and the queue variable of IntAut. To express this relationship, 
obj-ok uses the representation function / as follows. Recall that a state is of 
IntAut contains a queue variable Q, represented by a sequence and Head and 
Tail variables indicating which indexes are relevant in the current queue state. If 
obj-ok{is, cs,f) holds, then / indicates which node corresponds to each relevant 
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def 

rel{is, cs,f) = enqueue_ok{is , cs,f) A dequeue_ok{is , cs,f) A obj_ok{is, cs,f) A 
nds_ok{is, cs,f) A distinctness-ok{is , cs,f) A procs-ok{is, cs,f) A 
injective-ok{is, cs,f) A access_safety_ok{is, cs,f) 

Fig. 10. The rel predicate 



obj_ok{is, cs,f) ‘^= 

f{is.Q.Head) = cs.Head.ptrA (1) 

f{is.Q.Tail)^next.ptr=nullA (2) 

{f {is. Q. Tail) = cs.Tail.ptr V (3o) 

{f {is. Q. Tail) = cs.Tail.ptr^next.ptr A ^cs.free{cs.Tail.ptr) A 
cs.Tail.ptr 7 ^ null)) A (36) 

VAN* is. Q. Head < i < is. Q. Tail ^ 

{i 7 ^ is. Q. Tail {f{i)-^next).ptr = f{i + 1)) A (4a) 

is.Q.seq{i) = {f{i)-^val).ptr A (46) 

^cs.free{f{i)) A (4c) 

f{%) 7 ^ null (4d) 



Fig. 11. The obj_ok predicate 



position in is.Q.seq; i.e., for each i S [is. Q. Head + 1 ■ ■ ■ is.Q.Tail], f{i) is the 
queue node in cs containing the value is.Q.seq[i], and f {is .Q .Head) indicates 
which queue node in cs is the dummy node pointed to by cs.Head.ptr. The latter 
is stated by Conjunct (1) of obj-ok. Conjunct (2) states that the last node in the 
queue has a null next pointer. Conjunct (3) captures the fact that Tail can “lag” 
behind the real tail of the queue: either Tail is accurate (3a), or Tail.ptr points 
to the next-to-last node in the queue, and several other properties that help the 
proof to go through hold (3b). Conjunct (4) expresses the properties of the nodes 
in the concrete queue: the pointer value of the next field of each node points to 
the node corresponding to the next index (4a); the value in each relevant node 
is the value in the corresponding position in is.Q.seq (4b); none of the relevant 
nodes is unallocated or in the freelist (4c); and none of the relevant nodes is 
null (4d). 

Predicates enqueuc-ok and dequeuc-ok (Fig. 12) play the same role as 
basic-ok and dequeuer_ok in the backward simulation. The other predicates 
capture properties needed to support the proof of the other properties. 
nds-ok{is, cs,f) expresses properties of a node as it gets initialised (Fig. 12). 
The distinctness-ok predicate expresses that various values are distinct, for ex- 
ample, that nodes being initialised by two different processes are different. The 
procs-ok predicate expresses several properties about the private variables of pro- 
cesses. Some of its subpredicates are shown in Fig. 12. For example, procs-ok_15 
says that if a process p is executing Enqueue and pcp is e_9, then the pointer 
component of nextp is null. The injectivc-ok predicate ensures that each node 
corresponds to only one index (in the relevant range), so that modifications to 
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enqueue^ok{is, cs,f) ^ 

Vp • {cs.pcp = idle is.pcp — idle) A 

{pc_e_i_9(cs, p) V cs.pCp — e_13 is.pCp — enqueuing{cs.valuep)) A 
{cs.pCp — e_17 V cs.pCp — enq_resp is.pCp — enq_resp) 
dcf 

nds^ok(is, cs,/) = Vp • (pc_e_;SL-Z5(cs, p) —>cs.free?(cs.nodep) A cs.nodsp ^ nnZ/) A 
(pc_e_5_i5(cs, p) cs. nodsp-^ value. ptr — cs.valuep) A 

(pc_e_4_i5(cs, p) cs.nodsp-^next.ptr — null) 

procs^ok^5{is , cs,f) ^ 

Vp • pc_e_5_P(cs, p) A cs.Jiextp.ptr = null^ 

cs.nextp.ver <. cs.tailp.ptr-^next.verV (cs.nextp — cs.tailp.ptr-^next A 
cs.tailp — cs.TailA cs.tailp.ptr — f{is.Q.Tail)) 

def 

procs^ok^l5{is, cs,f) = Vp • cs.pCp — e_9 ^ cs.nextp.ptr — null 

def 

procs^ok^l 6{is , cs, f) = V p • pc^e^6-13{cs, p) cs.nodep.ptr ^ cs.tailp.ptr 
injective^ok{is , cs,/) ^ 

V 2 , jf • is. Tail < Z < is. Head A is. Tail < / < is. Head A f{i) — f{j) i — j 



Fig. 12. Some predicates used in FS7?. A predicate of the form pc-e-m_n{cs, p), where 
m, 11 are integers, holds when cs.pCp = e_i for some i € [m, n] 



a node corresponding to one index do not destroy properties required of nodes 
corresponding to other indexes. The accesssafety-ok predicate says that the im- 
plementation never dereferences null or accesses a node that is in unalloc, which 
is important for correct interaction with a memory allocator. 

As in the backward simulation proof, we use a step-correspondence function 
to determine the intermediate action sequence to choose given a particular tran- 
sition of the concrete automaton. (Again, we always choose either a single action, 
or the empty action sequence.) As before, this function maps each external ac- 
tion to itself, and maps all internal actions to the empty action sequence, with 
the following exceptions: e_9_yeSp, which models a successful CAS at line E9, is 
mapped to do-enq^; d_9_yeSp is mapped to deq-nonemptyp, cL3p is mapped to 
obaeive-emptyp, and dS-yeSp is mapped to deq-cmptyp. 

In contrast to the backward simulation, we do not need to specify a function 
to calculate the intermediate state, because this is uniquely determined by the 
intermediate pre-state and the action (if any) chosen. However, we specify a wit- 
ness function that shows how to choose the new / so that FSR holds between 
the concrete and intermediate post-states. For a representation function /, con- 
crete action a, concrete state cs and intermediate state is, the witness function 
returns the function f'=f(B {is. Q. Tail -I- 1 cs.nodcp}. 

We now present a careful manual proof that ohj-ok is preserved across tran- 
sitions that represent the execution of line E9 by some process, where the CAS 
is successful. This is intended to illustrate the use of the representation func- 
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tion, and the style of reasoning we use to verify algorithms that employ dynamic 
memory. 

Consider a concrete transition cs — > cs' , where a = e-Q-yes^ for some p, 
intermediate state is and representation function /, and let as' and f' be respec- 
tively the intermediate state and function determined by the step-correspondence 
and witness functions. When we say that part of the simulation relation holds 
in the pre-state (resp. holds in the post-state), we mean that it is true for cs, is 
and / (resp. cs' , is',f'). 

The step-correspondence associates e-9-yeSp with do-enqp(cs.valuep), so we 
need to show that if the precondition of e-9-yeSp holds in the pre-state (see 
Fig. 6) and rel{is, cs,f) then obj-ok{is' , cs' , f) . 

First, we make some observations about the transition: 

cs.Tail.ptr = cs.tailp.ptr = f{is.Q.Tail) (i) 

f '{is' .Q. Tail) = cs.nodep (ii) 

Claim (i) is shown using procs-ok_l5 to yield that cs.nextp.ptr = null, and then 
using procs-okJS to yield that cs.Tail.ptr = cs.tailp.ptr = f {is. Q .Tail). Claim 
(ii) follows immediately from the construction of /' and the effect of do-eripp. 

(1) of obj-ok is preserved because is'. Q. Head = is. Q. Head, but is. Q. Head < 
is. Q. Tail -\- 1 (this is a simple invariant of IntAut). Therefore is' .Q. Head yf 
is.Q.Tail-\- 1, so by construction of f and because obj_ok holds in the pre-state, 
f {as' .Q .Head) = /{is.Q.Head) = cs.Head.ptr = cs' .Head.ptr. 

For (2), by construction of f and the effect of do-enqp, f {is' .Q .Tail) = 
f'{is.Q.Tail-\- 1) = cs.nodep. Moreover, by nds-ok, cs.nodep^next.ptr = null. 
By procs-ok_16, cs.tailp.ptr cs.nodep, so cs.nodep'^next.ptr = null, and thus 

f' {is' .Q .Tail)'^next.ptr = cs .nodep'^next.ptr = null. 

We show that (3b) holds in the post-state, arguing each sub-conjunct in turn. 



f' {is' .Q. Tail) = cs.nodep 

= cs.tailp.ptr^next.ptr 
= cs.Tail.ptr^next.ptr 
= cs' .Tail.ptr'^next.ptr 



by (ii) above 
by construction of cs' 
by (i) above 

because cs' .Tail = cs.Tail 



cs' .free?{cs' .Tail.ptr) = cs.free?{cs' .Tail.ptr) 
= cs.free?{cs. Tail.ptr) 
= cs.free?{f{is.Q.Tail)) 
= false 



because cs' .free? = cs.free? 
because cs' .Tail = cs.Tail 
by (i) above 
conjunct 4c with 
i = IS. Q. Tail 



Now by claim (i), cs.Tail.ptr = f {is . Q .Tail) , so by Conjunct (4d) applied to 
is. Q. Tail, cs.Tail.ptr yf null. Therefore, cs' .Tail.ptr yf null by the effect of the 
e-9-yes transition, so the third conjunct is preserved. For the last conjunct of 
(3b) we have 
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f' {is' .Q .Tail) = cs.nodep by (ii) above 

yf cs.tailp.ptr by procs_oLA6 

= cs.Tail.ptT by (i) above 

= cs' .Tail.ptr 

We prove (4) by cases. For any i such that is'. Q. Head < i < is'. Q. Tail, 
either i = is. Q. Tail + 1 or is. Q. Head < i < is. Q. Tail. We treat the case in 
which i = is. Q. Tail + 1 first, is. Q. Tail + 1 = is'. Q. Tail so there is nothing to 
prove for (4a). For (4b) we have 



is' .Q.seq{i) = cs.valucp 

= cs.nodep^value.ptr 
= cs.nodep^ value.ptr 
= f '(i) lvalue, ptr 



by effect of do^enq^ 
and enqueue_ok 
by nds_ok 

by effect of e_9-yesWp 
by (ii) above 



4c and 4d follow from nds-ok and (ii) above. 

It remains to consider the case in which is. Q. Head < i < is. Q. Tail. For 4a, 
we further distinguish the cases in which i = is. Q. Tail and is. Q. Head < i < 
is. Q. Tail. For the first case, we have 



f ' {i)'i^ next.pt r = f{i)'i^next.ptr 

= cs.tailp.ptr’i^next.pti 
= cs.nodep 
= f'(is'.Q.Tail) 

= /'(i + l) 



because i ^ is. Q. Tail + 1 

by (i) above 
by effect of e-9-yeSp 
by (ii) above 
by effect of do_enq^ 



If is. Q. Head < i < is. Q. Tail, (4a) follows directly if we can show that 
/(z) yf cs.tailp.ptr. This is because i yf is. Q. Tail and so (4a) holds for i in the 
pre-state and 



{f{i)-^next).ptr = f{i + 1) => {f{i)^next).ptr = f{i + 1) given 

/(j) yf cs.tailp.ptr 

=y> {f'{i)'^next).ptr = f'{i -|- 1) i < is. Q. Tail so 

/'(*)= /(O 

and 

f'{i + l)=f{i + l) 

But if f{i) = cs.tailp.ptr then by injectivc-ok and (i) above, we have i = 
is. Q. Tail, contradicting the hypothesis that i < is. Q. Tail. 

(4b), (4c) and (4d) all follow for i from the fact that these conjuncts held in 
the pre-state and that because i yf is.Q.Tail+ 1, is' .Q.seq{i) = is.Q.seq{i) and 
/'(z) = /(z). Moreover, no value fields, nor free? are modified by the transition. 
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5 Experience with PVS 

In this section we describe our experience using PVS to prove that the relations 
presented in the previous sections are in fact simulations. We focus on the for- 
ward simulation from ConcAut to IntAut because of its greater complexity. The 
techniques used to verify the backward simulation are similar. 

The PVS system [3] provides a specification language, which we used to 
define the notions of backward and forward simulation. Using techniques adapted 
from [8], we also encoded the three automata, AhsAut, IntAut and ConcAut, as 
well as the simulation relations, BSR and FSR. 

One of the goals of our verification effort was to construct the proof without 
requiring the human prover to attend to the tedious and uninformative aspects. 
We achieved this using two techniques: using the step-correspondence and wit- 
ness functions, and dividing the forward simulation proof into many small, man- 
ageable parts. As noted in Sect. 4.2, using predefined functions to instantiate 
existentially quantified variables relieves the user of needing to manually instan- 
tiate these variables during proofs. Also, as described below, dividing the proof 
into many small parts allowed us to quickly isolate the parts of the proof that 
required human insight. 

We divided the forward simulation verification condition into over 1000 lem- 
mas. One lemma covers condition 1 of Fig. 7; for each concrete action associated 
by the step-correspondence with a nonempty intermediate action sequence, there 
is a lemma stating that if the concrete precondition holds, then the intermediate 
precondition holds in all related states; and finally, more than 900 preservation 
lemmas, each asserting that a part of the simulation relation is preserved across 
some transition. We used the mechanical proof facilities of PVS to prove a large 
proportion of these lemmas automatically. 

Constructing proofs for the preservation lemmas constituted by far the bulk 
of the proof effort, and so we describe the techniques used to achieve this here. 
The conjuncts of the simulation relation can be divided into a small number of 
classes, depending on the presence and structure of the top level quantification: 
for example, enqueue-ok and all the subpredicates of procs-ok are universally 
quantified over a single process, so fall into the same class. For each of these 
classes, we developed a simple strategy that set up a proof, to be continued 
by a user or automated strategy. All these strategies begin by executing a strat- 
egy called Begin-Simstep, which evaluates the step-correspondence and witness 
functions, and expands the definition of rel and the definitions on which it de- 
pends, resulting in a set of subformulae each making assertions about is, cs 
and /. Begin-SimStep then labels each subformulae, allowing strategies applied 
later to refer to each subformula by name. Because rel is too complex to be 
analysed by PVS’s automated strategies, Begin-SimStep hides the subformulae 
of rel. In PVS, each subgoal of a proof is associated with a set of formulae that 
are hidden] that is, they are not visible to any strategies, unless they are first 
revealed. 

After Begin-SimStep has completed, one or more strategies are applied, each 
of which applies proof steps that are always needed to prove a conjunct of a par- 
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ticular form. For example, the SimStep-obj-ok strategy, which is applied at the 
beginning of preservation proofs involving obj_ok (which has no top-level quan- 
tifier), expands obj-ok in the consequent, and generates a set of new subgoals, 
where each conjunct must be shown to hold in the post-state. Once this strategy 
is completed, either an automatic strategy is applied to attempt to complete the 
proof without user intervention, if possible, or PVS waits for a command to be 
invoked interactively. 

Now we have a situation in which the user is presented with a set of subgoals. 
Using primitive PVS proof commands and the labels defined by Begin-SimStep, 
the user reveals antecedent formulae that assert facts about the pre-state that 
are relevant to the subgoal at hand and instantiates any universally quantified 
variables. Once the relevant formulae have been revealed and instantiated, it 
remains to invoke the PVS automated strategies on the subgoal. These strate- 
gies apply boolean decision procedures, rewrite rules, and sometimes heuristic 
instantiations to attempt to complete the goal. 

The limited form of interaction with the theorem prover not only reduces 
user-effort, but also improves the robustness of the proof. As the project pro- 
gressed, we often made small modifications to the simulation relation and even 
the automata. Because we used proof commands that did not depend on fine 
aspects of the formulae being proved, we were able to successfully re-run most 
proofs after a modification, without changing the proofs themselves. 

6 Concluding Remarks 

We have presented a variation on the practical lock-free FIFO queue algorithm 
of Michael and Scott, and described a semi-automated proof of its linearisability 
we developed using the PVS system. The algorithm and specification are both 
modelled using I/O automata, and the proof is based on a combination of for- 
ward and backward simulation proofs. Our work illustrates some techniques for 
modelling and reasoning about dynamically allocated memory, and also some 
techniques for fully automating the easy parts of proofs, allowing the human 
prover to focus on aspects of the proof that require human insight. Future work 
includes refining our techniques to increase automation and applicability, as well 
as applying them to other problems. We expect that our efforts to automate 
the easy parts of the proof will enable us to tackle larger and more complicated 
problems in the future. 
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Abstract. In this paper, we present an approach for modeling an existing web 
application using communicating finite automata model based on the user- 
defined properties to be validated. We elaborate a method for automatic 
generation of such a model from a recorded browsing session. The obtained 
model could then be used to verify properties with a model checker, as well as 
for regression testing and documentation. Unlike previous attempts, our 
approach is oriented towards complex multi-window/frame applications. We 
present an implementation of the approach that uses the model checker Spin 
and provide an example. 



1 Introduction 

The Internet has reshaped the way people deal with information. In partieular, web 
applieations have affeeted the daily life in many ways, where they are used in 
information management/gathering, e-eommeree, software development, learning, 
edueation, entertainment, ete. With sueh pervasive and radieal growth of web 
applieations, eorreetness is a primary eoneem, espeeially that Web Applieations 
(WA) internet with many eomponents sueh as seripts (CGI, ASP, JSP, PHP, ete.), 
browsers, proxy servers, baekend databases, ete. Unlike traditional software, WA 
have an extremely short development and evolution life eyele and often have a large 
number of untrained users that eould experiment with the WA unpredietably. 
Therefore, thorough analysis and verifieation of WA is indispensable to assure the 
release of high quality applieations. In reeent years, software eommunity started to 
aequire formal methods as a praetieal and reliable solution to analyze various 
applieations. In this paper, we present a formal approaeh for modeling web 
applieations using a eommunieating automata model. We observe the external 
behavior of an explored part of a web applieation using a monitoring tool. The 
observed behavior is then eonverted into eommunieating automata representing all 
windows, frames, and framesets of the applieation under test. The obtained model 
eould then be used to verify user-defined properties of the applieation with a model 
eheeker. Our implementation of the approaeh uses the model eheeker Spin. In 
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Section 2, we present an overview of the main notions of the web. In Section 3, we 
discuss the related work on formal modeling and analysis of web applications. 
Section 4 introduces our approach. In Section 5, we suggest a method to model a 
browsing session of a single window application by a single automaton. Section 6 
describes a method to partition a single browsing session into local sessions and to 
convert the local sessions into communicating automata. In Section 7, we present the 
implementation of the approach using Spin and provide a case study in Section 8. We 
conclude in Section 9. 



2 Preliminaries 

We present the main terminology encountered in studying web applications. Further 
information can be found in [1,2,3]. A web application is defined in [3] as “a software 
application that is accessible using a web browser or HTTP user agent. It typically 
consists of a thin-client tier (the web browser), a presentation tier (web servers), an 
application tier (application servers) and a database tier”. We see a web application as 
an application providing interactive services by rendering web resources in the form 
of web pages (containing text and images, forms and etc.). A page can be static, 
residing on the server, or dynamic, resulting from the execution of a script at the 
server or the client side. A page is rendered by a browser to the user in windows. A 
form is a section of a web page that includes textual content, controls (buttons, 
checkboxes, etc.), optional labels, an action and a method. A frame element is an 
HTML tag that defines a frame. It includes a source src attribute specifying the URI 
of the source (initial) page loaded in the frame and an optional name attribute that 
assigns a name to the frame. A frameset element is an HTML tag that groups frame 
elements and possibly other frameset elements. The HTML document that describes 
the layout of frames is called the Frameset document having a frameset element that 
can be nested at any level. A Frameset document can be viewed as a frame tree 
whose leaves are frame elements and internal nodes are frameset elements. Detailed 
information on forms, frames, and HTTP protocol can be found in [1,3,20,21]. Note 
that we distinguish between two classes of WA: applications whose behavior is 
independent of its history and does not rely on the client's or the server's state. The 
second class represents WA whose behavior is determined by its history and thus 
affected by previous information kept at the client/server side (such as cookies). In 
this work, we consider the first class of WA where the same HTTP request always 
has the same response independently of past information in previous request/response 
pairs. 

3 Related Work 

Formal modeling of web applications is a relatively new research direction. Previous 
work on the topic includes modeling approaches that target the verification of such 
applications [25,26,27,28], testing [29,30,32,32], design and implementation 
[10,11,12,13,14]. In [25,26] an approach is presented where a web site is modeled as 
a directed graph. A node in the graph represents a web page and the edges represent 
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links clicked. If the page contains frames the graph node is then a tree whose tree 
nodes are pages loaded in frames and tree edges are labeled by frame names. This 
model is used to verify properties of web sites with frames. However, only static 
pages are considered in this work, concurrent behavior of multiple windows is not 
modeled, and all the links whose targets could create new independent windows are 
treated as broken links. Besides, any frameset that could be present in the application 
is completely ignored. Also, in the model, a page loaded in an unnamed window (as a 
result of the predefined target " blank" associated with a link) is represented as a 
graph node that replaces the existing node as if the page is loaded on top of page 
where the link was clicked; this incorrectness is due to the inadequacy of the 
proposed model to represent concurrent behavior of multiple windows. In [27,28] the 
authors present a model based on Petri nets to model check static hyperdocuments 
[27] and framed pages [28]. While Petri nets can express parallel and concurrent 
behavior, the authors build the overall state space as input of the model checker, 
which is a tedious and erroneous approach especially with large applications with 
several frames and windows. [25,26,27,28] do not tackle the modeling and 
verification of form-based pages that are dynamically generated by a server program, 
neither concurrent behavior of applications with multiple windows. The work in 
[29,30] focuses on inferring a UML model of web applications. This model, merely a 
class diagram, is mainly used for the static analysis of web applications: HTML code 
inspection and scanning, data flow analysis, and semi automatic test case generation. 
In [31], the above mentioned modeling technique is extended such that a web 
application is executed to extract models for dynamic web pages using server's access 
logs. These logs present limited information on the requests since only the request 
headers are logged. In case dynamic pages are generated based on POST method 
requests, the form data submitted is usually stored in the message body of the request; 
thus, making those pages requests undistinguishable and introduce unnecessary non- 
determinism into the resulting model. Besides, the approach is inadequate for 
modeling concurrent behavior of frames and multiple windows. In [32], a modeling 
technique for web applications is presented based on regular expressions. The focus 
is on modeling the behavior of web applications, consisting of merely dynamically 
generated pages, for the purpose of functional testing. Other approaches for modeling 
web applications are oriented towards the design rather than analysis of WA. These 
include object oriented based models [10] and statechart based models [11,12,13,14], 
that are tailored to forward engineering, logical and hierarchical representation of 
web applications. Such models are not available for analyzing existing WA 
developed without formal models. Each of the existing related work concentrates on 
some aspects of web applications leaving out other aspects that remain untouched, or 
unfeasible to model using the corresponding proposed approach. These attempts 
indicate that formal modeling of WA is still an open complex problem especially 
when it comes down to modeling multiple frames and windows, and properties which 
have to reflect various concerns of different stakeholders of WA. 

In this paper, we attempt to develop a modeling approach that could produce a 
finite automaton model tuned to features of WA that have to be validated, while 
delegating the task of property verification to an existing model checker. We 
elaborate a black-box (dynamic) approach by executing the web application under 
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test (WAUT) and analyzing only its external behavior without any access to server 
programs or databases. The observations are provided by a monitoring tool, a proxy 
server [5] or an off-the-shelf network monitoring tool [18], where HTTP requests and 
responses are logged. Our model is a system of communicating automata representing 
all windows, frames, and framesets of the application under test. The existence of 
frames, framesets, and windows reflects concurrent behavior of the WAUT, where 
these objects affect each other behaviors via links and forms with specified targets. 
Therefore, a suitable and natural modeling technique is communicating automata, 
where the burden of building a global state graph of the model is left to a model 
checker. As opposed to the existing approaches, we model not only static pages, but 
also dynamic pages with form filling (with GET and POST methods), frames and 
frameset behavior, multiple windows, and their concurrent behavior. Generally 
speaking, one could build a special web-oriented model checker, as in [26], to verify 
specific properties. This task requires the building of all the necessary algorithms 
from scratch. We opt to the use of an existing model checker. Spin, used in several 
industrial applications [22], such that we only have to describe our model in the 
model checker's input language. 



4 Observing Web Application 

To define a formal model of a web application in case when the code of the 
application is available, one may apply abstraction techniques developed in software 
reverse engineering following a static (white -box based) approach [7,8,9]. To build a 
formal model according to a dynamic (black-box based) approach, one executes a 
given application and uses only the observations of an external behavior of the 
application [15,16,17,31]. In case of web applications that rely on the HTTP protocol 
considered in this work, an “external” behavior consists of requests and responses. In 
our framework, we follow the dynamic approach and assume that the 
request/response traffic between a client side and a server in the WA under test is 
observable. One possible way of achieving this is to use a proxy server [5]. A proxy 
server monitors the traffic between the client and the server and records it in proxy 
logs. The proxy logs contain the requests for the pages and the responses to these 
requests. 

With this approach, a behavior of a WAUT, we call it a browsing session, is 
interpreted as a possible sequence of web pages that have the same domain name 
intermittent with the corresponding requests. Note that a behavior of a WA is 
independent of the navigation aids provided by the browser (back button, forward 
button, etc.). In other words, we build a model that is independent of a browser. We 
assume that a next request is not submitted before the browser delivers a response to a 
previous request. If the user clicks a link, and that leads to a page with k frames then 
k+\ request/response pairs are observed. The first request/response pair corresponds 
to the link clicked and thus to the frameset document; and k requests, initiated by the 
browser, along with their responses, correspond to the URIs defined in the frameset 
document. Exhaustive exploration could hardly be achieved for non-trivial web 
applications with a database tier. This is why we have to build a model just for a part 
of the WAUT, which is explored in a browsing session. To generate sequences of 
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requests, instead of the user, one may eonsider a erawler that automatieally explores 
links in the WAUT [6], though in ease of pages with forms to fill, the user aetions 
would still be required. In the next seetion, we explain our approaeh for building a 
finite automaton that models a browsing session. 



5 Modeling Single Window Web Applications 

We first present our modeling approaeh for web applieations whose web pages do not 
have frames and assume that the WAUT is browsed in a single browser window, in 
other words, that all the links have undefined target attributes. Later we provide 
extensions to more eomplex applieations. 

The purpose of building a formal model for a WAUT is to validate whether the 
applieation exhibits eertain predefined properties. We assume that the properties to be 
speeified in a temporal logie of a ehosen model eheeker are eomposed of atomie 
propositions, and for eaeh visited page the value of eaeh proposition is uniquely 
determined by the eontent of the page, be it dynamie or statie. These propositions 
refer to the page attributes that have to be eheeked (and refleeted in a model). These 
attributes ean be of various types, for instanee: a numerieal type to eount the 
oeeurrenee of a eertain entity, a string type to denote the domain name of a page, or 
features of a page link, sueh as a hypertext assoeiated with the link. However, there 
are eases when an attribute representing a eertain feature of the visited page eannot be 
defined for another page. For instanee, a Boolean attribute that indieates whether the 
menu is framed in a page that does not eontain menus, or an attribute representing the 
pereentage of the number of oeeurrenees of a eertain string with respeet to the 
number of all the strings in a page that eontains no text. In sueh eases, we assign to 
these attributes the value “not available”. The atomie propositions that refer to sueh 
attributes are then false in the eorresponding pages. In the following, we deseribe 
how to determine automata that model an observed behavior of a WAUT based on 
the information available in the eorresponding browsing session. The session ineludes 
requests initiated by the user, namely links elieked and filled form submissions, as 
well as requests initiated by the browser, namely requests for URIs present in an 
HTTP-EQUIV tag [3,4]; for simplieity, we eall those URIs implicit links. 

5.1 Definitions 

Eaeh request is represented by a string 1. In ease the request method is Get or Head, / 
is the URI sent in the request. If the request is for a filled form then we represent it in 
the form a?d, where a is the form aetion and d is the form data set that eorresponds to 
the data fields filled in the form; in ease of the Get method, data set is a part of the 
URI sent in the request, while in ease of Post method, data set is ineluded in the 
message body as a data stream. 

Eaeh response eorresponding to a visited page is abstraeted by a tuple <m, c, 7, L, 
V>, where u denotes the request / identifying the page; c e C represents the status 
eode of the page, C is the set of valid status eodes defined as integers ranging 
between 100 and 599 [20]; I is the set of URIs speeified by the aetion attribute of 
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each form in the page; L is the set of URIs associated with links, including the 
implicit links if any, in the page {L does not include links that cause the scrolling to 
sections in the same page); and F is a vector <v\, Vt>, where v, is the valuation of 
the page attribute i and k is the number of all the page attributes over which the 
atomic propositions are defined. Pages with status code 3xx have their URL u 
different from the request / that triggered the response due to a redirection to another 
location of the pages. Pages with status code 4xx or 5xx may or may not have links 
leading back to the application. 

A browsing session is a Request/Response Sequence RRS = <«o, Co, h, Lq, Vq> l\ 
<ui, Cl, 7i, Li, Vi> ... /„ <u„, c„, /„, L„, V„>, where <mq, Cq, /q, Lq, Vq> is the default 
page displayed in the browser window from which the first request was triggered; this 
page is not observed in the browsing session, therefore, Mq and Co are null, and /q, Lq, 
and Fo are empty sets; /, is a request that is followed by the response page <m„ c„ 

F>; for all i > 1, /, e F,-i if /, is a request corresponding to a clicked or implicit 
link, or if /, is of the form then a, e /,_i; and for all i > 0 I,- = Ui if Ct 3xx; 
(otherwise, /, m,); and n is the total number of requests in the browsing session, 

starting from the first request l\ for the initial (home) page of the application. Page 
attributes or atomic propositions, along with u and c, are considered as state attributes 
and used for model checking in a way similar to Kripke structure [19]. 

We say that a link of the application under test is explored in a browsing session if 
it's URJ is one of the requests in the browsing session; otherwise, we say that the link 
is unexplored. Similarly, we say that a form is explored if its action a appears in one 
of the requests a?d in the browsing session; otherwise we say the form is unexplored. 

Two pages <m„ Ct, F> and <Uj, Cj, Ij, Lj, Vj> have a repeated (common) link if 
Li n Lj 0; similarly, a repeated form exists if li n Ij 0. 

5.2 Converting a Browsing Session into an Antomaton 

In this section, we provide a high-level description of our algorithm to convert RRS 
into an automaton, called a session automaton. 

Algorithm 1. Given a browsing session RRS = <«o, Co, h, Lo, Vg> l\ <Ui, C\, I\, L\, 
Vi> ... l„ <u„, c„, /„, L„, V„>, where n is the total number of observed responses: 

1 . The tuple <ug, Cg, Ig, Lg, Vg> is mapped into a designated state called inactive, 
denoted Sg, where Ug and Cg are null, and Ig, Lg, and Vg are empty sets. 

2. For all i > 0, a tuple < m „ c „ h, Li, F> corresponds to a state of the session 
automaton. Tuples <m„ c „ li, Li, F,> and <Uj, Cj, Ij, Lj, Vj>, where j > i, are 
mapped into the same state if c, = c,, 7, = 7,, 7., = Lj, and F, = Vj. Let S denote the 
set of thus defined states. 

3. The set of events of the automaton is defined by the union of the sets F , A, 
Req. r= {I \ I e Li, I < i < n} is the set of all the URIs associated with links in 
the observed responses, Zl c {a | a e li, 1 < ; < «} is the set of all form actions 
that correspond to the unexplored forms in the observed responses, Req is the 
set of all the observed requests. Thus, Fkj A u Req is the alphabet of the 
automaton, denoted Z. 
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4. Each triple (<m„ c„ /,, Li, V,>, /,+i, <m,+i, c,+i, /,+i, L,+i, F,+i>) defines a transition 

(s',-, li, where St, St+i correspond to the pages <m„ c,-, /,, L,-, F,>, c,+i, 

/,+i, Li+i, Vi+\> respectively, and /,+i e L, if /,+i is a request corresponding to a 
clicked or implicit link, or if /,+i is of the form then a,+i g and /,+i = 

M,-+i if c,+i 3xx; (otherwise, /,+i m,+i); 

5. Each request corresponding to an explored repeated form or link defines a 
transition from the state where it occurs to the state that corresponds to the 
response of the submitted filled form or clicked link. 

6. Each request corresponding to an unexplored link / g L, or unexplored form a 
G li defines a transition from the state representing the page <«,, Ci, /,, Li, V,> to 
a designated state, called a trap state that represents the unexplored part of the 
WAUT and whose attributes are undefined. Let T denote the set of thus defined 
transitions. 

7. The session automaton is A/ms = < 5 U {trap}, ^o, -5 T>. 

The automaton that models the whole WAUT could be built from an exhaustive 
browsing session obtained by exploring each link, and filling in every possible way 
and submitting each form, on every page of the application (which is usually 
unfeasible). 

The following is a fragment of a browsing session representing five web pages, 
and Figure 1 shows the automaton that represents the browsing session, where state Ss 
is a deadlock state representing an error page whose status code is 404. URLl, URL2, 
and URL3 (named as such for simplicity) represent few unexplored links that label 
transitions to the trap state. 

GET http://www.crim.ca HTTP/1.0 
Host: www.crim.ca 

Accept: application/vnd.ms-excel, application/msword, application/vnd.ms-powerpoint, image/gif, 
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 4.0) 

Accept-Language: en-us 

end of http request 
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HTTP/1.1 200 OK 
Content-Type: text/html 
Content-Length: 18316 

Server: Apache/1.3.9 (Unix) mod_perl/1.21 mod_ssl/2.4.9 OpenSSL/0.9.4 

Date: Wed, 10 Apr2003 19:40:02 GMT 

<HTML> 

<HEAD> <LINK rel=''stylesheet" href=7styles.css"> 

<TITLE> CRIM</TITLE></HEAD> ... 

...<a href=7rd/”> recherche-developpement </a> ... 

</HTML> 

end of http response 

6 Web Applications with Frames and Multiple Windows 

In the previous section, we presented an automata model for single window web 
applications. However, web applications often use frames and multiple windows. 
These options allow rendering several pages at the same time, thus introducing 
concurrency in the behaviors of such web applications. Therefore, using a single 
automaton is insufficient to adequately model a concurrent behavior of web 
applications with several ffames/windows. In this section, we extend our approach, 
using communicating finite automata, to model such web applications, which we call 
multi-display WA for simplicity. Before we introduce our extended approach, we 
define the elements of a browsing session of a multi-display WA. 

6.1 Definitions 

A response in a multi-display WA is defined as a tuple <u, c, /, F, L, V>, where u, c, 
and V are the same as in Section 5. / and L are extended to include for each action and 
link the corresponding target. Therefore, an element of T is a tuple </, />, where / is a 
URI associated with a link and t is the corresponding target or the empty string 8 
when no target is defined. Similarly, an element of / becomes a tuple <a, t>, where a 
denotes a form action and t its corresponding target. F is a frame tree defined in the 
page and whose leaves are frames and internal nodes are framesets. A frame is a tuple 
of the form <f, b> where / is the URI defined by the value of the src attribute of the 
HTML frame element and b is the frame name. We denote by leaves{F) a function 
that returns the set of leaf nodes (frames) of the tree F. 

We define a browsing session of a multi-display WA as a sequence of requests 
(along with their corresponding targets) and responses. For simplicity, we keep using 
the term Request/Response Sequence (RRS) to represent a browsing session. 

A RRS = <Mo, Co, /o, Fo, Lq, Vo> <r i, l\, t\> <U\, C\, I\, F\, L\, V\> ... <r„, l„, t„> <u„, 
c„, In, F„, L„, V„>, where n is the total number of requests in the browsing session 
starting from <ri, b, ti>. <ri, /,> represents a request such that r, is a string denoting 
the request header field, “referer”, which is the URI of the page where the request 
was triggered; and </,, /,> is such that 

• if the request is for a filled form then /, is of the form where a, forms with 
the target /, a tuple <a„ /,> e 7/ of the page <Uj, Cj, Ij, Fj, Lj, Vj>, where m, = r„ 

• if the request is for a frame source page then </,, /,> g leaves{Fi) of the page 
<Uj, Cj, Ij, Fj, Lj, Vj>, where Uj = r,-, or 
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• otherwise (if the request is for a link, clicked or implicit), then </,, t,> g Lj of 
the page <Uj, Cj, Ij, Fj, Lj, Vj>, where Uj = r,-,. 

Notice that, similar to the case of a single window WA, <mq, Cq, Iq, Fq, Lq, Vq> 
corresponds to the initial default page displayed in the browser window such that mq, 
Co are null, and /q, Fq, Lq, Vq are empty sets; <ri, /i, t{> includes the URI l\ of the 
starting page, and r\ and t\ are the empty string 8. In addition, /, = m, if Ct 3xx; 
otherwise, /, m, and <m„ c„ /„ F,> immediately follows r, in the RRS. 

6.2 Basic Assumptions 

Before we elaborate the model of a multi-display WA, we state basic assumptions 
about the observed browsing session of the application under test. As in Section 4, we 
assume that a request is not submitted before the browser delivers the responses to the 
requests for all frames source pages or for pages displayed in different windows. 
Also, the following assumptions are essential due to a limitation to directly determine 
from a request the window/frame from which it was triggered. An observed 
request/response pair does not include the name of the window/frame targeted by the 
corresponding URI. To determine the window/frame, we track the “referer” header 
field in the request which is the URI of the page, where the request is triggered. Thus 
the following assumptions must hold in the observed browsing session: 

1. At each moment, different pages are displayed in frames/windows. If two 
pages have links to the same page, then only one request corresponding to one 
of the links is present in the session. 

2. If a link is repeated in the same page with different targets and a request for 
that link is in the session, then this request corresponds to the first instance of 
that link appearing on the page. 

These assumptions are not difficult to satisfy when the browsing session is created 
by the tester. 

6.3 Communicating Finite Automata Model of Multi-display Web Applieations 

Here we describe how an observed browsing session can be modeled by a system of 
communicating automata. Given the browsing session, we first determine local 
browsing sessions that correspond to the behaviors of the entities in the browsed part 
of the WAUT, such as windows, frames, and framesets, each of which is modeled by 
an automaton. Then we explain how to convert the local browsing sessions into 
communicating automata and present the corresponding algorithm which is an 
extension of Algorithm 1 presented in Section 5.2. 

Finite state automata communicate synchronously by rendezvous, executing 
common actions. Such communication is formalized by the parallel composition 
operator on automata. Formally, two communicating automata Hi = < 5i, S'oi, i), T\> 
and H 2 = < S 2 , S 02 , T'l > are composed using the || operator. The resulting 
automaton, denoted Hi || H 2 , is a tuple < S, ^o, 27, T>, where ^ (^oi, ■? 02 ) and E 
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= u 2 ^; and S Si X S2 and T are the smallest sets obtained by applying the 
following rules: 

• If (^1, e, ^'i) e Ti,ei 2 ^, and (^i, ^2) e S, then (^'i, ^2) e S, and ((^i, ^2), e, (^'i, 
^2)) e T. 

• If (^2, e, s'2) e T2, e £ 2 i, and (^i, ^2) e S, then (^i, s' 2) e S, and ((si, S2), e, (si, 
^ 2)) e T. 

• If (si, e, s'l) e Ti, ($2, e, s'2) e T2, and (si, S2) e S, then (s'l, s'2) e S, and ((si, 
S2), e, (s'l, s'2)) e T. 

The eomposition is assoeiative and ean be applied to finitely many automata. 

6.3.1 Local Browsing Sessions 

A browsing session represents the behavior of k eommunieating entities, namely, 
browser's main and independent windows, frames and framesets, denoted Oi, 02, ..., 
Ok, where Oi eorresponds to the browser's main window. The entities eorresponding to 
independent windows are determined by analyzing the targets present in the requests; 
if the target in a request is not an existing frame name, it eorresponds to an 
independent window; for eaeh request whose target is “ blank”, a new entity is 
defined eorresponding to a new unnamed independent window. The entities that 
eorrespond to frames are determined by the frame names indieated in the frame trees 
of the response pages; where eaeh frame entity is uniquely identified by <f, b> and 
the URI M of the frameset doeument where the eorresponding frame tree is defined. 
The entities eorresponding to framesets are identified by analyzing the internal nodes 
of the frame trees. The number of eommunieating entities k is then defined as follows. 
Given a browsing session, <mq, Cq, h, Fq, Lq, Vq> <ri, k, q> <mi, Ci, 7 i, Fi, L\, V\> . . . 
<r„, /„, t„> <Un, c„, In, F„, L„, V„>, let {t\, ..., tq), sueh that q< n, he, the set of all the 
distinet targets observed in the requests ineluding window names, frame names, and 
predefined targets ("_parent", " top", " self, " blank"). Let {b\, ..., bp) be the set of 
all the frame names defined in all the responses, and m the number of all the 
framesets defined as well in all the responses. Then, k^\ + \ {t\, . . ., u {b\, ...,bp) 
- {ti \ ti = "_top" or ti = "_parent" or t,- = "_self ' or t, = "_blank" or t,- = 8 } | + | {<r,-, /,■, tj> 

I ti = " blank"} I + m. We further analyze the hierarehieal relationship among the 
different entities of the applieation. We eonsider eaeh window entity as a window tree 
whose root node represents the window itself. The first frame tree oeeurring in 
(frameset doeument loaded into) the window is appended to the root of the window 
tree. If a request's target is a frame name, sueh that the response is another frameset 
doeument (having a frame tree), in the window tree, the response's frame tree is 
appended to the node of the targeted frame. Similarly, if the target is a frame name, 
frameset, or the window itself, any subsequent ehildren are removed from the node of 
the targeted entity and replaeed by the response's frame tree if any. 

The loeal browsing sessions {RRS\, ..., RRSt) eorresponding to the observed 
behavior of k entities of the applieation are determined as follows. A request/response 
pair <rj, Ij, tj> <Uj, Cj, Ij, Fj, Lj, V/> belongs to a RRSi if the target tj refers to the entity 
Oi. Also, the RRS of eaeh frame/frameset that eould be a ehild of o, eontains the same 
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request <rj, Ij, tj> whose response is the inaetive page. At the same time, the RRS of 
the (targeting) entity from whieh <r,, Ij, tj> is triggered must eontain <rj, Ij, tj> itself 
with its response being the page where the request is initiated. This is explained by 
the faet that the targeting entity does not ehange its displayed page. However, if the 
target tj is "_parent", " top", or a parent entity name, then the response in the RRS of 
the targeting entity is the inaetive page. Similarly, the RRS of eaeh frame/frameset 
that is a ehild of the targeted entity eontains the same request <rj, Ij, tj> whose 
response is the inaetive page. This means that those frames and framesets are 
deaetivated and erased from the window. If the target attribute is absent or " self 
then <rj, Ij, tj> <Uj, Cj, Ij, Fj, Lj, Vp> belongs to a RRSj provided that the request is 
triggered from the last page displayed in the eorresponding entity o,. Following is a 
high-level deseription of the algorithm that determines the loeal sessions. 

Algorithm 2. Sessions RRS^, i= are formed using the following algorithm: 

1. RRS\ <«o, Co, /o, Fq, To, fo> eorresponds to the inaetive page of the RRS of 
the main window similar to the inaetive page defined in Seetion 4. For i > 1, 
RRSi := <Ue, Ce, !&, Fq, Lq, VS> , is defined similarly to <«o, Cq, h, Fq, Lq, Vq> 
whieh eorresponds to the inaetive page from whieh the loeal session starts. 

2. The first request response pair <ri, /i, T> <ui, Ci, 7i, Fi, L\, V{> is appended to 
the session of the browser's main window, i.e., RRS\ ~ RRS\ <r\, h, t\> <U\, Ci, 
luFuL,, Fi>. 

3. For eaeh request/response pair <r„ /,, tj> <Uj, Cj, Ij, Fj, Lj, Vj>,j > 1, 

a. if the target tj refers to entity o,-, <r,, Ij, tj> <Uj, Cj, Ij, Fj, Lj, Vj> is 
appended to i.e., RRSi ~ RRSi <rj, Ij, tj> <uj, Cj, Ij, Fj, Lj, Vj>. At the 
same time, <rj, /,, tj> <ue, ce, la Fa La Fef is appended to the sessions 
of all the frames and framesets (if any) that are ehildren of o,. 

b. If the “referer” r, is equal to the URI of the last response in RRSi then, 

i. If the target tj eorresponds to a parent entity, the response 
eorresponding to <rj, Ij, tj> in RRSi is the inaetive page <Ua Ca 
la Fa La Thus, RRSi — RRSi <rj, Ij, tj> <ua Ca le, F& 
La V(F- At the same time, <rj, Ij, t,> <ua ca la F'e, La VeF is 
also appended to the sessions of all the frames and framesets 
that are ehildren of the targeted parent; otherwise, 

ii. the response to <r,, /,, tj> is a tuple <u, c, /, F, L, V> sueh that r, 
= u. Thus, RRSi ~ RRSi <rj, Ij, tp> <u, c, I, F, L, V>. 

e. If the target tj = " self or tj = 8 and r, is the URI of the last page 
displayed in RRSi, then RRSi \= RRSi <rj, Ij, tj> <Uj, Cj, Ij, Fj, Lj, Vj>. 



6.3.2 Communicating Finite Automata Model 

To build an automata model of a browsing session of a multi-display WA, we eonvert 
eaeh loeal browsing session RRSi = <Uia Cia ha Fia Lia <rn, hu hi> <m,i, c,i, 
hi, Fii, Lii, ... ^fiim ktm ^imy hrm Fif,i, Li,,,, luto au automaton H/, 

ealled the local session automaton, by extending Algorithm 1 of Seetion 5.2. 

The set of events 2) of the automaton is defined by the union of the following 
four sets /) , A,, Reqi, and <P,. Similar to what is previously defined, /) ={</,, h> | </,, 
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tp> G Li^, 1 <w<m] is the set of all the URIs associated with links in the observed 
responses, zl, c {<a„ t,> | <a„ t,> g 7,^, 1 < w < m} is the set of all form actions that 
correspond to the unexplored forms in the observed responses, and Reqi is the set of 
all the observed requests. ^{<fu b,> \ <fi, bi> e leaves{Fi^), 1 <w<m} is the set of 
URIs corresponding to the source pages loaded in the frames. 

Algorithm 3. Given an entity o, and its local browsing session RRSi, we extend 
Algorithm 1 to convert RRSi into a local session automaton At as follows. 

1 . Algorithm 1 is used to convert RRSi into 

2. The set of events 2^ is extended to include the set <?, of URIs corresponding to 
the source pages loaded in the frames; thus, ~ u <P,. 

3. Each triple (<«,y, Cy, ly, Fy, Ly, Vy> <ry, ly, ty> <Ui0, CiQ, he, Fi 0 , Lie, Vi(T-) 
defines a transition {sy, <ry, ly, ty>, ^,o), where Sy, Sm correspond to the pages 
<Uy, Cy, ly, Fy, Ly, Vy>, <Ui0, Ci0, he, Fj0, Lie, Vi(F, respectively; 

4. Each triple (F^y, Cy, ly^ Fy, Ly, -^y+i? b^ij+i:> ^ij+u Ey+i^) 

such that <Uy, Cy, hj, Fy, Ly, Vy> = <M,y+l, Cy+l, ly+U E’y+1, Ly+i, Vy+\>, dcfinCS d 
transition (sy, <ry, ly, tij>, Sy), where Sy correspond to <Uy, Cy, hj, Fy, Ly, Vy>; 

5. Every event corresponding to a request targeting o, itself labels a transition 
from every state of the automaton to the state of the corresponding response 
page. 

The last three steps of the algorithm define the transitions labeled by the events 
shared by different automata. Step 3 of the algorithm defines transitions labeled by a 
request initiated by o, or one of its siblings/children, and whose target is a parent 
entity. Then, o, is deactivated and Ai is in the inactive state Sio. Step 4 defines 
transitions labeled by a request initiated by o, targeting another entity which is not a 
parent of o,. In this case, o, does not change its displayed page and Ai remains in the 
current state. The last step of the algorithm states that a shared event targeting o, is 
not under the control of Ai and thus should label transitions from every state of Ai to 
the corresponding state. Thus, in case of an ill-designed application or unreasonable 
user behavior, where multiple instances of a same window created using the 
predefined target “ blank”, are all treated as a single entity, avoiding state explosion. 

Note that there are cases where a frameset in a web application is merely used to 
group nested frames/framesets within a certain layout without having any behavior 
itself (it is not the target of any of its children's links). As a result, the corresponding 
automaton has a single state (inactive). Therefore, to simplify the model, we 
discard every automaton that models a frameset entity without any behavior. An 
automaton for a frameset has more than one state in the case when a request, initiated 
from a child frame of the frameset and whose target is "_parent", exists in the 
observed browsing session. As described in Section 6.3.1, in the frameset automaton 
(initially in state S'o), a transition labeled by the event that corresponds to the request 
exists from to the state corresponding to the page displayed in the frameset. At the 
same time, this event labels transitions in the automaton of each child entity of the 
frameset from every state to its inactive state. This behavior of framesets in a WA is 
not modeled in any previous work that we know about. 
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Let ^ 1 , {k-m < z < k, m is the total number of framesets, k is the total number 

of existing entities in the application) be the automata that model z windows, frames, 
and possibly framesets. The composition automata A is || ... \\A^, such that A = <S 
U {trap}, So, Z, T>. The initial state of^ is ^ (■?oi, •••, ■?oz); the set of events ZofA 
is the union of all Z,; the set of states S and the transition relation T of A are defined 
according to the semantics of the composition operator ||. The trap state of^ is trap = 
{trapi, ..., trapz). 

7 Implementing the Approach 

In this section we describe the framework and the tool that implement our approach 
for modeling a browsing session recorded when a WAUT is navigated. 

7.1 Framework 

Our approach is implemented following the framework illustrated in Figure 2: 

• The user/tester starts by selecting the web application to test and defining some 
desired attributes. These attributes, which are defined prior to the analysis 
process, are used in formulating the properties to verify on the application. 

• A monitoring tool intercepts FITTP requests and responses during the 
navigation of the WAUT performed by the user. 

• The intercepted data is fed to an analysis tool that continuously analyzes the 
data in real time (online mode), incrementally builds an internal data structure 
of the automata model of the browsing session, and translates it into XML- 
Promela. The XML-Promela file is then imported to Promela using a 
functionality of aSpin [23], an extension of Spin model checker [22] that 
includes the feature of importing a XML-Promela file to Promela language and 
exporting a Promela file to XML-Promela. The specification of XML-Promela 
syntax is defined in the Document Type Definition (DTD) file provided with 
aSpin. 




Fig-2. Framework 
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• aSpin verifies the properties against the model and generates a counter example 
if a property is not satisfied. 

7.2 Online Model Extractor 

The Online Model Extractor is implemented in Java as an experimental multithreaded 
tool that has the following components: 

1. A graphical user interface where a range of web related attributes that 
characterize web applications is provided, and a window showing the progress 
of the analysis performed during the browsing session. 

2. An HTTP Reader that continuously reads intercepted data in an online mode by 
a monitoring tool, HTTP proxy [5] in our case. 

3. A Web Modeler that parses and analyzes the request/response pairs. This 
module incrementally builds an internal data structure representing the 
automata model of the WAUT. 

4. An XML-Creator that reads the internal data structure and translates it into an 
XML-Promela based tree which is continuously updated. 



8 Case Study 

In this section, we illustrate the applicability of our approach using a browsing 
session of the web application of the Eclipse Consortium, www.eclipse.org. The 
corresponding web site uses framed pages and multiple windows. The first step in 
modeling the WAUT is to specify the desired attributes. This is done using the 
interface of the Model Extractor. 




Fig.3. Attribute input window 
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Fig. 3 shows the attribute input window in the tool. Next, we navigate the 
application while the request/response pairs are intercepted by the proxy server. The 
intercepted pairs are fed into the Model Extractor/Manipulator, which produces the 
model of the application in XML Promela. The resulting XML file is imported into 
aSpin. The extracted model consists of ten processes reflecting the fact that the 
application includes seven frames and two windows in which 26 distinct web pages 
were visited. The frames are within the main browser's window and the second 
independent window has no frames within it. The global state graph corresponding to 
our model consists of 847 states and 9652 transitions (stored + matched). In order to 
prove the validity of our modeling approach, we verified various properties on the 
model of the application. These properties include reachability properties, and the 
checking for frame errors such as depth of frames does not exceed a user defined 
threshold, frames having same name are not active simultaneously, and pages 
displayed in frames are within the domain name of the application. As an example, 
we explain the verification of three properties. The first property requires that in the 
window mainW, and thus the frames within it, and the window blankO, the number of 
links in the displayed pages should be balanced, i.e., the difference between the 
number of links in the displayed pages in the two windows should not exceed a 
certain number which we fix to 15. This global property requires the exploration of 
all possible executions of the transitions of the automata of the main window mainW, 
the frames displayed with it, and the independent window blankO. The second 
property requires the absence of a frames error where frames having same names are 
not active simultaneously. The third property is a reachability property that requires 
that given three web pages, program, conference, and homejnain, there exists at 
least a path where page program is reachable from page homejnain without going 
through page conference. Note that pages program and conference are loaded in the 
independent window blankO and page homejnain is loaded in the frame main_0. The 
first property is formulated in LTL as follows: [] || q), where p and q are predicates 

such that p = nLinks2 - (nLinksl + nLinks _bannerO + nLinksjiavO + nLinksjnainO) 
<= 15, and q = nLinks2 - {nLinksl + nLinks _banner 5 + nLinks _homejiav5 + 
nLinks jiav 5 + nLinks jnainS) <=15. Each variable in these predicates is associated 
to a process and represents a page attribute that counts the number of links in the 
page. nLinks2 is associated to the process of blankO, nLinksl to the process of 
mainW, and the rest of the variables are associated to the processes of the frames. 
This property is not satisfied in the model and the verification result produces a 
counter example simulating a trace that violates the property. The second property is 
formulated in LTL as follows: [] p, where p = duplicateFramesjnainW^ = 0 such 
that duplicateFramesjnainW is a Boolean variable that is set to True if two frames 
having same name are active simultaneously. This property holds in our model. To 
verify the third property, we negate it and check if it holds in the model. The negation 
of the property becomes: on all paths from page homejnain to page program, page 
conference is present. We use the LTL property pattern. Exist Between, from the 
repository in [24] to formulate this property as follows: [] {homejnain && ! program 
— ^ ((! program) U (( conference && ! program) || [] (! program)))). This property 
holds in the model, thus there is no path from page home jnam to page program 
where page conference is absent. Thus, the original property does not hold in model. 
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9 Conclusion 

In this paper, we presented an approaeh to formally model web applieations for the 
purpose of verifieation and validation using model eheeking. We used the dynamie 
(blaek-box based) approaeh by exeeuting the applieation under test (navigation and 
form filling), and observing the external behavior of the applieation by intereepting 
HTTP requests and responses using a proxy server. We devised algorithms to eonvert 
the observed behavior, whieh we eall a browsing session, into an automata based 
model. In ease of applieations with frames and multiple windows that exhibit 
eoneurrent behavior, the browsing session is partitioned into loeal browsing sessions, 
eaeh eorresponding to the frame/window/frameset entities in the applieation under 
test. These loeal sessions are then eonverted into eommunieating automata. We also 
presented the framework and tools that implemented the proposed approaeh, and 
demonstrated the approaeh by applying it to a real web applieation. The eonstrueted 
models ean also be used for other purposes sueh as doeumenting, testing, and 
maintenanee of web applieations. Currently, we are experimenting with the tool using 
several types of web applieations that refleet both good and bad praetiees in the 
development of WA. Our approaeh is based on the assumption that we observe 
behavior of WA whieh is independent of its history. As a future extension, we intend 
to treat WA behavior that is based on the observation of eookies in requests and 
responses. 
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Abstract. This paper proposes an algorithm for the construction of an 
MSC graph from a given set of actual behaviors of an existing concurrent 
system which has repetitive subfunctions. Such a graph can then be 
checked for safe realizability and be used as input to existing synthesis 
techniques. 



1 Introduction 

A concurrent system consists of two or more processes communicating among 
themselves via message exchanges. Each individual functionality (i.e., intended 
or actual behavior) of such a system can be viewed as a sequence of subfunc- 
tions. Often, depictions of individual intended behaviors of a concurrent system 
are given by designers as Message Sequence Charts (MSCs) [1, 2]. An individual 
MSC is a visual description of a series of message exchanges among commu- 
nicating processes in a concurrent system where the local view of the message 
exchanges is a total order with respect to each process but the global view is 
a partial order. A tuple consisting of a local view for each process of the mes- 
sage exchanges depicted in an MSC uniquely determines that MSC. Thus, an 
MSC represents a partial order execution of a concurrent system which stands 
for a set of linearizations (total order executions of the system) determined by 
considering all possible interleavings of concurrent message exchanges implied 
by the partial order. 

Formal semantics associated with MSCs provides a basis for their analysis 
such as detecting timing conflicts and race conditions [3], non-local choices [4], 
model checking [5], and checking safe realizability [6] (revised version appeared 
as [7]). Safe realizability is a property that characterizes whether behaviors rep- 
resented by a given set of MSCs can be realizable by some deadlock-free imple- 
mentation of communicating processes. [7] shows that if the given set of MSCs 
is safely realizable then an approach similar to existing synthesis algorithms can 
be used to synthesize a deadlock-free design. If it is not, then unspecified (and 
possibly unwanted) MSCs that are implied can be detected and fed back to the 
design process. While checking for safe realizability of a given set of MSCs that 
does not imply any repetitive system subfunctions can be done in polynomial 



D. de Frutos-Escrig and M. Nunez (Eds.): FORTE 2004, LNCS 3235, pp. 133—149, 2004. 
(c) IFIP International Federation for Information Processing 2004 



134 Hasan Ural and Hiisnii Yenigiin 



time [7], that of a given bounded MSC graph is in EXPSPACE [8], which is later 
shown to be EXPSPACE-complete [9]. 

Design representations are helpful not only for implementing software sys- 
tems, but also for software maintenance, e.g. to detect and eliminate errors in 
a system, to extend the capability of a system, or to adapt a system to differ- 
ent operating environments. Further, the developers of a new software system 
whose functionality contains some of the functionality of an existing system can 
benefit by using the related part of the design of the existing system. However, 
up-to-date or complete designs of many existing systems may not always be 
available. 

One of the aims of the reverse engineering [10, 11] is to recover the design of an 
existing system from the run time behavior of its implementation. In this paper, 
we consider the reverse engineering of designs of existing concurrent systems 
from given sets of observations of their implementations. Here, a given set of 
observations consists of individual linearizations of a set of MSCs that is not 
given. We propose an algorithm for constructing an MSC graph from a given 
set of observations of an existing concurrent system as a representation of the 
system’s design. 

We assume that every repetitive subfunction of the system (if any) is repre- 
sented in the given set of observations at least twice: once with no occurrence 
or one occurrence, and once with two or more consecutive occurrences. This as- 
sumption stems from the fact that some repetitive subfunctions can be skipped 
during executions, whereas others cannot. 

When the resulting graph is acyclic, it is guaranteed that the system’s func- 
tionality is free from repetitive subfunctions. Otherwise, the resulting MSC graph 
is cyclic due to the existence of repetitive subfunctions in system’s behavior. In 
either case, the resulting MSC graph may then be checked for safe realizability 
and, when found safely realizable, can be used directly as input to the existing 
automated synthesis techniques. 

The rest of the paper is organized as follows: Section 2 introduces the ter- 
minology and notation used throughout the paper. Section 3 gives the formal 
definition of the problem. Section 4 presents the construction of an MSC graph 
from a given set of observations. Section 5 discusses some open problems and 
gives the concluding remarks. 

2 Preliminaries 

The notation we will be using is directly adopted from [7]. A concurrent system 
V is & set of processes V = {Pi, P 2 , • ■ • , ^n}, communicating with each other by 
passing messages from an alphabet A, over infinite slot (not necessarily FIFO) 
buffers. An event labeled as snd{i, j, a) denotes the transmission of a message a G 
S by the process Pi to the process Pj. Similarly, an event labeled as rcv{j,i,a) 
denotes the reception of a message a by the process Pj, which must have been 
sent by Pi. 
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We use [n] to denote the set {1,2, . . . ,n}. Let Sf = {snd{i, j,a)\j S [n],a S 
^}, El = {rcv(i,j,a)\j € [n],a G E}, and Ei = Ef U E\ be the set of send 
event labels, the set of receive event labels, and the set of event labels of the 
process Pi, respectively. Then we define, E’^ = E'' = and 

E = VJ S'" , as the set of send event labels, set of receive event labels, and the 
set of event labels, respectively. 

A word w over an alphabet A is a finite sequence of elements from that 
alphabet. For two words w and w' , juxtaposition of the two words, ww' , denotes 
the concatenation of w and w' . w' is said to be a prefix of w, if there exists 
w” such that w = w'w" . For an integer fc > 0, denotes the concatenation 
of k copies of w, where is defined to be the empty word. We will use the 
notation w* to denote concatenation of 0 or more copies, and w“'" to denote 
concatenation of 1 or more copies of the word w. 

Given a word w over E and an event label a € E, let ff{w, a) be the number 
of occurrences of ainw.w is said to be well-formed if Vprefix w' of w, \/i,j G [n] 
and Va G E, ff{w',snd{i,j,a)) — ff{w' ,rcv{j,i,a)) > 0. In other words, every 
receive event must be preceded by a matching send event, w is said to be eomplete 
if Vi,j G [n] and Va G E, ff{w, snd{i, j,a)) = ff{w,rcv{j,i,a)). That is, every 
message a sent by Pi to Pj must be received by Pj, within the word. 

Given a word w and a set K, we use w\k (projection onto K) to denote the 
word that is derived by removing all the elements in w that are not in K. We use 
the same notation to denote the restriction of the domain of a binary relation R 
onto a set K. That is, R\k is the projection of R onto K. 

Again, we directly adopt the formal definition of an MSG as introduced in [7]. 
A A-labeled MSG M for a concurrent system V is composed of the following 
components^: 

(i) A finite set S of send events and a finite set R of receive events. Let 

E=S\JR. ^ 

(ii) A mapping I : E ^ E that maps each event to a label such that 1{S) C E^ 
and 1{R) C E^. 

(iii) A bijection f : S R mapping each send event e with its matching receive 
event such that if /(e) = snd{i,j,a) then l{f{e)) = rcv{j,i,a). 

(iv) A mapping p \ E ^ [n] such that if /(e) = snd{i,j,a) then p{e) = i, and 
if /(e) = rcv{i,j,a) then p(e) = i. p simply gives the process on which e 
occurs. Let Ei = {e £ E\p{e) = i} be set of events of Pi for i £ [n], 

(v) For each i £ [n], a total order <i on Ei, such that when the relation < is 
defined to be 

<= Uig[„] <i U{(s, /(s))|s G S} 
the transitive closure <* of < is a partial order on E. 

The total order <i on Ei gives a strict execution order of the events of Pi as 
seen on the vertical process lines of Pi in the visual representation of the MSG. 

^ Note that, this definition of MSCs does not include the notion of co-region (the 
region on a process line in which the events of the processes are not ordered) in 
MSCs which is also omitted in this paper. 
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The pairs (s, /(s)) S < correspond, in the visual representation, to the message 
passing arrows from the process line of p{s) to the process line of p(/(s)). 

Throughout the paper, S and V are assumed to be fixed and all the MSCs 
mentioned will be if-labeled and defined on V. Let M denote the set of all 
T'-labeled MSCs for V. 

Let \E\ denote the cardinality of the set E. A permutation of the events E of 
an MSC as 6162 . . . e\E\ is valid when Vi, j G [|A|], Ci <* Cj implies i < j. In other 
words, the total order induced by the given permutation on E is consistent with 
the partial order <*. A word re on if is a linearization of an MSC M if there exists 
a valid permutation eiC2 . . . e\E\ of M such that w = l{ei)l{e2) ■ ■ • l{e\E\)- The 
language of an MSC M, denoted by L{M), is the set of all linearizations of M. 
Two MSCs M and M' are considered to be equal, M = M', iff L{M) = L{M'). 

Note that, by definition, if w G L{M), then w is well-formed and complete. 
Further note that, \/w,w' G L{M), w|i;. = w'\Ei- In other words, the projections 
of the words in L{M) onto the event labels of a process is unique. This follows 
from the fact that all the valid permutations of M must respect the total order 
<i which is included in <*. In fact, this unique word, which will be denoted 
by M\i, is the concatenation of the labels of the events that appear on the 
vertical line of Pi in the visual representation of M . Therefore, as shown in [7], 
given a well-formed and complete word w, there exists a unique MSC M, such 
that w G L{M), under a non-degeneracy assumption (that there is no message 
overtaking between same labeled events) which we also adopt in this paper. We 
will denote this unique MSC by msc{w). We also let w = L{msc{w)). 

Due to this fact, an MSC can be characterized by the sequence of sequences 
of the event labels that appear on the processes, i.e. M = {M\i \ i G [n]). Given 
such a sequence, the actual MSC can be constructed easily as explained in [7]. 
Roughly, the procedure is to scan each M\i starting from the beginning. During 
this scanning, a send event with a label snd{i, j, a) is matched with the first 
not-yet-matched receive event with a label rcv{j,i,a) in M\j. 

Proposition 1. Let M and M' he two MSCs. M = M' iff for eaeh proeess Pi, 
MU = M'\,. 

Proof. The proof follows from the fact that MSCs are fully characterized by their 
projections onto the event labels in the processes as explained above. □ 

Consider the visual representation of an MSC M and imagine that we draw 
a line through M by crossing each process line exactly once, and without crossing 
any message arrows. Such a line divides M into two parts Mp (the part above 
the cutting line) and Mg (the part below the cutting line). Mp and Mg can be 
shown to be MSCs again. In fact, Mp and Mg are, what we are going to call 
below, a prefix of M and a suffix of M, respectively. 

Formally, given two MSCs M and M', with the set of events respectively E 
and E', M' is said to be a prefix (resp. suffix) of M, iff: 
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(i) E' C E. 

(ii) e £ E' implies Ve' £ E, if e' <* e then e' £ E' (resp. e £ E' implies 
Ve' £ E, if e <* e' then e' £ E') 

(iii) e £ E' C\ S implies /(e) G E' (resp. e £ E' C\ R implies /”^(e) G E' , 
where is the inverse of the bijection /) 

(iv) S' = S f] E' , R' = Rf] E', I' = 1\e>, f = f\E>, p' = p\e', and Vi G [n], 
<i=<i \e'- 

The imaginary cutting line mentioned in the intuitive explanation above is 
the one that crosses Pi’s line right below (resp. right above) the largest (resp. 
the smallest) event e G E[ with respect to the total order <j. 

Let M, Mp and Mg be MSCs with the corresponding set of events E, Ep 
and Eg such that Mp is a prefix of M, Mg is a suffix oi M , Ep f] Eg = it> and 
E = EpU Eg. Then, M is said to be the sequential composition of Mp and Mg, 
denoted by the juxtaposition of Mp and Mg as MpMg. Given two MSCs M' and 
M", L{M'M") = {w|w G v7v7',w' £ L{M'),w" £ L{M")). 

For an integer k > 0, denotes the sequential composition of k copies 

of M, where M^^l is defined to be the empty MSG, i.e. an MSG with the empty 
set of events. We will use the notation M* to denote sequential composition of 
0 or more copies, and to denote sequential composition of 1 or more copies 
of the MSG M. 

While describing the scenarios that a concurrent system must perform, a set 
of MSCs can be used. However, when this set gets large, it is usually presented in 
a more structured way by using High Level MSCs, or HMSCs, which is formally 
equivalent to an MSG graph given below. An MSG graph is a labeled transition 
system G = (V,vo,Vf,T), where M is a finite set of nodes, vo,Vf £ V are the 
entry and exit nodes (respectively) . The relation T C M x M x G gives the edges 
between the nodes with the labels from M. A path in G is a sequence of edges 

{vi,Mi,V2){v2,M2,Vz){vz,M's„Vi) ■ ■ ■ {Vra, Mm , Vm+l) 

Such a path is said to start at node vi and end at node Vm+i- The language of 
a path is given by the concatenation of the language of the MSCs that appear on 
the edges, L{Mi)L{M 2 ) ■ ■ ■ L{Mm)- Given an ordered pair of nodes (v,v'), the 
language of the pair (v, v'), denoted by L{v, v'), is the union of the languages of 
all the paths that start at v and end at v' . The language of a node v, denoted by 
L{v), is L{v,Vf). The language of an MSG graph G is defined as L{G) = L{vq)- 

We will use the notation v v' to denote {v, M, v') £ T. 

3 Problem Definition 

Each function implemented by a concurrent system can be viewed as a combi- 
nation of some subfunctions. For example, in a file transfer function of a com- 
munication protocol, we may have connection establishment (CE), data transfer 
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Fig. 1. An example MSC Graph 



(DT), connection release (CR) subfunctions. If one could identify the subfunc- 
tions as they are being executed, then a typical execution would consist of the 
following steps: 

CE, DT, DT, ..., DT, CR (1) 

Based on the size of the data being transferred, the subfunction DT would be 
executed repeatedly, as many times it is required to transfer the amount of data 
at hand. If we consider how one would start describing such a function at an 
abstract level when the system was first built, it is not unreasonable to imagine 
that an MSC graph similar to the one given Figure 1 had been used. 

In the context of reverse engineering, several attempts appeared in the lit- 
erature to recover the design of an implementation from a given set of obser- 
vations [12, 13, 14, 15, 16, 17]. However, if the sequence given in (1) is reverse 
engineered with the current techniques, the existence of repetitions of DT will 
cause problems. In general, it is not possible to decide if the repetitions of DT 
in (1) are due to a loop or due to the sequential appearance of DT in the design. 
Current techniques favor the latter and therefore, do not attempt to recover 
a design with the loops. In this paper, we will introduce a method that will help 
recover designs with loops. 

As observations, we consider the execution logs (logs of message transmis- 
sions and receptions of the processes) of an implementation Imp of a concurrent 
system. In other words, if S is the set of messages used for the communication 
between the processes of Imp, then an observation is a well-formed and com- 
plete word over S. We assume that an observation w G S* corresponds to a 
complete execution of a single function of Imp, and the functions are assumed 
to start from the initial system state, and end back at the initial system state, 
without going through the initial system state. That is, if w is an observation and 
the system is at the initial state, then after performing the message exchanges 
given in w (in the order they appear in w), the system goes back to the initial 
state right after the last member of w (which must be a reception since w is 
complete) is realized. Furthermore, at no point in w, the system must be in the 
initial system state, since otherwise the prefix of w up to that point would be 
considered as a separate observation. 

Suppose that we are given a set of observations O. In Section 2, it is shown 
that a well-formed and complete word corresponds to a unique MSC. Consider 
the MSC msc{w) corresponding to an observation w € O, and a word w' G 
L(msc{w)) but w' ^ O. Since the individual processes are behaving, from their 
local point of view, exactly in the same way for both w and w' , although not given 
as an observation, w' must also be an observation of Imp. Only the interleaving 
preferences between the processes change from w to w' . Therefore, the given set 
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of observations O, together with these implied observations, actually corresponds 
to a wider set which is: 



O = [J tc = [J L{msc{w)) 

wGO wGO 

Since each given observation in w € O actually corresponds to an MSC msc{w), 
we consider our input to be the set of MSCs M = {msc{w) \ w S O}, and we 
will consider an observation to be an MSC from now on unless stated otherwise. 

In our view of a function being composed of subfunctions, we also consider 
a subfunction to be specified by an MSC. This can be justified by considering 
that all the messages sent within a subfunction will be consumed within the same 
subfunction. In an observation M, which is given as a single MSC, the MSCs 
corresponding to the subfunctions are not apparent. However, our purpose is not 
to identify the MSCs of all the subfunctions one by one, but rather to identify 
those MSCs that correspond to repetitive subfunctions. 

Note that, if there are any loops in the design of Imp, and if an observation 
M G M is generated by more than one iteration of some loop, then there must 
be some repeated pattern in M where the pattern being repeated is generated 
by the iterations of the loop. However, the converse is not correct in general, i.e., 
a repeated pattern seen in an observation is not necessarily due to a loop. 

To be able to infer a loop in the design by looking at observations, we demand 
some evidence. We do not readily accept that a repeated pattern seen in a single 
observation is due to a loop. However, if the same pattern is seen different number 
of repetitions within the same context, then we assume this is a sufficient evidence 
for the existence a loop. Below is the formal definition of the notion of this 
evidence. 

Definition 1. An MSC M is said to be the basic repetitive MSC of MSC M' 
if M' = for some k > 2 and there does not exist a basic repetitive MSC 

ofM. 

Definition 2. Two MSCs M\ and M 2 are said to infer M to be repetitive within 
the context Mp-Mg if all the following are satisfied: 

(i) M does not have a basic repetitive MSC; 

(ii) Ml = fo r some k > 2; 

(Hi) M is not a suffix of Mp; 

(iv) M is not a prefix of Mg ; 

(v) either M 2 = MpMg (in which case M is said to be while-repetitive^ 
or M 2 = MpMMg (in which case M is said to be repeat-repetitive/ 

Note that Definition 2 captures the essence of two different repetitive sub- 
functions, one which can be skipped, whereas the other cannot be skipped during 
the execution of the system. In order to differentiate these two different types, 
we call them as while and repeat repetitive respectively, by using an analogy to 
standard programming loop types. 
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What we require in observations to infer a loop is that, there must be an 
observation in which the loop is iterated k > 2 times, and there must also be 
another observation in which the same loop iterated the least possible number 
of times (which is 0 for a while loop, and 1 for a repeat loop). Furthermore, 
these two observations must have exactly the same prefix before the iterations 
of M , and exactly the same suffix after the iterations of M, that is they must 
appear within the same context. Under such an evidence, M will be assumed to 
be generated by a loop in the design, or more precisely, by the matching loops 
(sending and receiving matching messages) in the processes. 

Suppose that M is found to be while-repetitive under the evidence of two 
observations Mi and M 2 with the prefix Mp and suffix Mg, and suppose that M 
is indeed generated by a loop in the design. Then the state right before the 
execution of M, and right after the execution of M are the same. Hence, any 
MSC in the form MpM*Mg must be realizable by Imp. A similar argument can 
be applied to show that when M is found to be repeat-repetitive, any MSC in 
the form MpM~^Mg must be realizable by Imp. 

Since we assume that Imp does not go through the initial system state during 
the execution of an observation, Mp and Mg in Definition 2 must not be empty. 
This can be justified by the following observation. If M is repetitive, then the 
state just before and just after an iteration of M are the same. If Mp is empty, 
then M starts its execution from the initial state, since the observations start 
from the initial state. After the first iteration of M, the system will again be 
at the initial state. However, this is the definition of a function in our setting, 
hence M and Mg must be given as separate observations. Similarly, if Mg is 
empty, then the state after an iteration, hence before an iteration of M is the 
initial state, since observations are assumed to end at this state. In this case, Mp 
and M must be given as separate observations. 

It is also important to note that, an iteration of a loop in an observation is 
allowed only to provide the required evidence to infer a loop. Further, each repet- 
itive subfunction is inferred only once using the given observations. Moreover, 
in order to establish the relative ordering of two or more loops Zi, / 2 , . . . , /n in an 
MSC graph, k >2 iterations of at least two loops k and Ij need to be given in 
the same observation such that the relative ordering of a pair of loops li and Ik 
can be determined from the relative ordering of two pairs of loops li and Ij, 
and Ij and Ik, ^ < i, j,k < n, and by transitivity. 



4 Problem Solution 

When a pair of MSCs Mi and M 2 is identified within the given set At, such 
that Ml and M 2 infers M to be repetitive within the context Mp-Mg, then Mi 
and M 2 will be represented in the output MSC graph by using either one of 
the following templates, depending on whether it is while-repetitive (left) or 
repeat-repetitive (right) . 
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An algorithm that will find such pairs of MSCs, must identify the context 
part, i.e. common prefix Mp and the common suffix Ms, and must also check if 
the part remaining in the middle has a basic repetitive MSC. Before presenting 
such an algorithm, we need to introduce the following notions on MSCs. A com- 
mon prefix of two MSCs Mi and M 2 , is an MSC M, such that M is a prefix 
of both Ml and M 2 - The maximal common prefix of Mi and M 2 is a common 
prefix M of Mi and M 2 with the largest number of events. Similarly, M is said to 
be a common suffix of Mi and M 2 if it is a suffix of both Mi and M 2 . The com- 
mon suffix of Ml and M 2 with largest number of elements is called the maximal 
common suffix of Mi and M 2 . 

Suppose that M = MpMg. Given M and Mp, it is trivial to find Mg, by 
simply removing all the events in Mp from the first part of M . Similarly, when 
we are given M and Mg, removing all the events in Mg starting from the last 
part of M will give Mp. In both of these algorithms, we need to match the labels 
of the events. Let us assume that these algorithms are called as “remove_prefix” 
and “remove^uffix” , respectively. 

We can now present an algorithm that can check if two given MSCs identify 
a repetitive MSC. Without loss of generality, we assume that Mi has more events 
than M 2 . 

Recall that, in order to infer M to be repetitive from Mi and M 2 , we must 
have Ml = MpM^^^> Mg and either M 2 = MpMg or M 2 = MpMMg. The max- 
imal common prefix of Mi and M 2 will be consisting of Mp, followed by an 
optional single occurrence of M. In either case, however, M!^ in Algorithm 1 
given in Figure 2 must be empty (line 7). At line 10 and 11, we check if M" has 
a basic repetitive MSC, by using the algorithm “basic_repetitive_MSC” , which 
is explained in Section 4.1. For the time being, assume that it returns the basic 
repetitive MSC of its input MSC, if there exists one, or returns the empty MSC 
otherwise. If such an M does not exist, we may still infer a repetitive MSC. This 
corresponds to the case where Mi = MpM^‘^'> Mg and M 2 = MpMMg. In this 
specific case, the maximal common prefix M^p would be MpM. Line 12 checks 
this singularity, and the correct left context is calculated at line 13. 

However, if M” has a basic repetitive MSC M, then we decide if it is while- 
repetitive or repeat-repetitive, between the lines 18-23. Note that when M is 
found to be repeat-repetitive (line 19-20), M will be a common suffix of the 
maximal common prefix of Mi and M 2 . In order to find the correct left context, 
line 19 extracts this common suffix from M^p- 

Note that, there may be multiple ways for dividing Mi and M 2 to iden- 
tify Mp, M and Mg. For example, let Mi = MaMf,McMi,McMi,Md and 
let M 2 = MaMbMd. In this case, it is possible to infer M^Mc as while-repetitive 
within the context Ma~ M^Md. However, it is also possible to infer McMf, as 
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1: Mmp ~ maximaLcommon_prefix(Mi, M 2 ); 

2: M[ = remove_prefix(M„ip, Mi); 

3: M 2 = remove_prefix(M„ip, M 2 ); 

4: Ms = maximaLcommon_suf}ix(Mi, M 2 ); 

5: M" = remove_suffix(Ms, M(); 

6: M 2 ~ remove_suffix(Ms, M 2 ); 

7: if M2 is not empty or Mmp is empty or Ms is empty then 
8: Ml and M 2 do not infer a repetitive MSC 

9: else 

10: M = basic_repetitiveJVlSC(M"); 

11; if M is empty then 

12: if M" is a snfiix of Mmp then 

13: Mp = remove jufBx(M„ip, M"); 

14: Ml and M 2 infer M” to be repeat-repetitive within the context Mp-Ms 

15: else 

16: Ml and M 2 do not infer a repetitive MSC 

17: end if 

18; else if M is a suffix of Mmp then 
19: Mp = remove_suffix(M„ip, M); 

20: Ml and M 2 infer M to be repeat-repetitive within the context Mp-Ms 

21: else 

22: Ml and M 2 infer M to be while-repetitive within the context Mmp-Ms 

23: end if 

24: end if 

Fig. 2. Algorithm 1 - Checking if Mi and M 2 infers an MSC M to be repetitive 



while-repetitive within the context MaM^-Md- By convention, we prefer to keep 
preamble of the loop as long as possible, hence use the latter alternative. Note 
that, this is only a convention as both MaMt,{McMt,)* Md and Ma{Mt,Mc)* MbMd 
have the same language. Algorithm 1 implements this convention by extracting 
the maximal common prefix of Mi and M 2 at line 1. 

We explain four elementary functions and the algorithm ba- 
sic_repetitive_MSC referenced in Algorithm 1 in the following subsections. 



4.1 Finding the Basic Repetitive MSC 

In this subsection, we explain how to check the existence of and find the basic 
repetitive MSC M of a given MSC M' . 

Recall that M\i denotes the sequence of event labels of process Pi in the 
MSC M. If M' = it is obvious that for each process Pi, we have 

M'\i = M\iM\i---MU 

' V " 

k times 



In other words, we must see these repeating patterns in the events of the 
processes as well. Checking if a word w' consists of repetitions of another word w 
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is a well-known and well-studied problem (e.g. see [18]) in pattern matching and 
text processing. If w' = then r is called the power of w in w' (we are only 
interested in integer powers, although the general theory of repetitions in words 
considers rational powers as well), and w is called a root of w' . If w cannot be 
written as a repetition of another word, then it is called as primitive. Linear 
time algorithms exist to find the primitive root of a word. Note that a word is 
always a root of itself with power 1. 

Proposition 2. Given an MSC M' , let he the power of the primitive root of 
M'\i, where i € [n], and let r = gcd(ri, r 2 , . . . , r„). M' has a basie repetitive 
MSC iff r> 2. 

Proof. Assume that M' has a basic repetitive MSC, i.e. M' = for some M 
and k > 2. Since the projections onto the processes must be the same, M'\i = 
Therefore, ri = kr[ where r' is the power of the primitive root of M\i 
(note that is not necessarily primitive). Therefore fc is a common divisor 
of ri,r 2 , ■ • . , rn, and hence r = gcd{ri,r 2 , . . . , r^,) > k >2. 

For the proof of the reverse direction, assume that r >2. Consider an MSC M, 
where Mj^ is the first \E'f\/r event labels in M'\i. Note that M' = since 

process wise projections are the same. It remains to show that M does not have 
a basic repetitive MSC. In fact this must be true, since if M = ^ for some 

r' > 2, then we must have M' = \ However in this case, rr', which is 

strictly greater than r would be a common divisor of ri, ^ 2 , . . . , r„, contradicting 
with the fact that r = gcd{ri, r 2 , . . . ,r„). □ 

4.2 Ftinctions on Maximal Common Prefix SufRx, 
and Prefix— Suffix Removal 

Finding the maximal common prefix of two words is trivial, and based on scan- 
ning and comparing the elements of the words starting from the beginning and 
stopping when a difference is seen. 

Finding the maximal common prefix of two MSCs is not as trivial as the 
case of words, since we require the prefix to be an MSC as well. Let M' and 
M” be two MSCs. Consider again the sequence of event labels M'\i and M"\i 
of process Pi on M' and M". Note that M'\i and M”\i are words. Let Wi be the 
maximal common prefix of the words M'\i and M"\i. Note that the sequence 
of event labels {wi \ i G [n]) does not necessarily characterize an MSC. How- 
ever, this problem can be solved by removing some of the suffixes of wfs. Recall 
the procedure explained shortly in Section 2, for building an MSC based on 
a sequence of sequence of event labels. This procedure can be adapted to elim- 
inate the problematic suffixes in wfs while finding the maximal common prefix 
in the following way. Initially, all the event labels in Wi’s are unmarked. Then 
perform a scan on each Wi starting from the beginning. For each send event 
label of the form snd(i, j^a) in Wi, find the first unmarked event label of the 
form rcv{j,i,o) in Wj. If such an unmarked event could be found in Wj, mark 
both snd{i,j,a) and rcv{j,i,a) instances under consideration, and proceed to 
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the next send event in Wi. When we mark two such events, they are called as 
marking pairs. It is necessary to remember this association since, if and when 
one of them is removed, the other will also be removed in the second phase of 
this procedure. If no such an unmarked event could be found in Wj, then leave 
snd{i, j,a) and all the remaining events in Wi as unmarked. After this marking 
phase, we have an iterative suffix removal phase. For each wi, the suffix of Wi 
that starts with the first unmarked event label is removed. Note that, some of 
the event labels in such a suffix may be marked. While removing such a marked 
event label, the mark of its marking pair (which must also be present in some Wj 
as marked) is removed. This iteration continues until all the event labels in all 
the WiS, are marked. The remaining event labels characterize an MSC which is 
the maximal common prefix. Finding the maximal common suffix of two MSCs 
can be performed in a similar way, by adapting the approach in the procedure 
explained above. 

Given an MSC M and a prefix M' of M, removing the prefix M' can be 
performed by removing the event label sequence M'\i from the first part of 
M\i for each process Pi. Similarly, the removal of a suffix M' of M would be 
performed by removing the event label sequence M'\i from the last part of M|i 
for each process Pi. 

4.3 Forming the Final MSC Graph 

Algorithm 2 given in Figure 4 is used to produce an MSC graph based on a given 
set of MSCs At. It has two phases. The first phase considers every pair of 
MSCs Ml and M2 in A4 and checks whether Mi and M 2 infer a repetitive MSC. 
The output of the first phase is an MSC graph with a special structure. For each 
pair of MSCs that infer a repetitive MSC, a separate subgraph, that is disjoint 
with the rest of the graph except at vq and Vf, is created. Such a subgraph 
has a different structure depending on whether the inferred MSC is while — or 
repeat-repetitive, which are shown in Figure 3 at the top and in the middle, re- 
spectively. If an MSC M does not infer a repetitive MSC by pairing with another 
MSC, then a subgraph which consists of only (vo,M,Vf) is created, as shown 
at the bottom in Figure 3. We will call these subgraphs as paths below. These 
paths will be referenced using the labels of the edges. The loops in the labels of 
the paths will be represented by using *. The second column of Figure 3 gives 
the label template associated with each path type. 

As an example for the execution of the first phase, let us suppose that initially 
we have three MSCs 



Ma = M1M2M2M3M4M5, 

Mi) = Afi Af2M^2M3M4M4M^5, 

Mf. = MiMi^M4^Mii,. 

(2) 

Ma and Mf, infer M4 to be repeat-repetitive within the context M1M2 M3-M5. 
Hence 



Md = MiM!^^ M^MiMlMi) 
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Path types 



Path labels 




M 



Fig. 3. Three different path types 



is inferred as a path in G. Similarly, Ma and Me infer M2 to be a while-repetitive 
within the context of M1-M3M4M5. So 



Me = MiM2*M3M4Ms 



is inferred as a path in G. 

Note that the subgraph generated from Mi and M2 is guaranteed to represent 
both Ml and M2, i.e. the language of Mi and M2 are included in the language 
of the generated subgraph. Thus, Mi and M2 are marked for deletion since we 
generated a new path from them. However, if for an MSC Mi, there does not 
exist an MSC M2 which infers a repetitive MSC, then Mi will simply be put 
into G and left unmarked. At the end of the first phase, there is no other loop 
left to be inferred. However, all possible relative positions of these loops must be 
represented in the final MSC graph G' which is constructed in the second phase 
of Algorithm 2 . 

The MSC graph G constructed by the first phase can be nondeterministic. In 
other words, there may be two different paths with a nonempty common prefix. 
In general, there is no guarantee that the system state is the same after the 
execution of the same prefix along these different paths, since the observations 
only give the message exchanges, and the local actions within the processes are 
hidden from the observer. There needs to be some evidence in the observations 
that allow some paths to be merged. Especially when a given observation M is 
used in the generation of two different paths p\ and p2 with labels Mi and M2 
respectively, the execution of p\ and p2 also corresponds to the execution of M. 
Hence the system state along pi and p2 that correspond to the execution of M 
must be same, and therefore p\ and p2 need to be merged. 

The second phase of Algorithm 2 performs the merging of paths using Al- 
gorithm 3 given in Figure 5 . Since we need to know the actual observations 
from which a path p is generated, the first phase of the algorithm associates this 
information to the generated path p by src(p) . 

In the example above, after the first phase, MSCs M^, Mf, and M^ are marked 
and thus removed, and we have the paths corresponding to Md and Mg added 
to G. In the second phase, there are two paths Md and Mg in G. Since the 
sources of these two paths have a nonempty intersection, they will be in the 
same partition, which is actually the only partition of paths in this example. 
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1: j* phase 1: infer loops and form G* j 
2: initially all the MSCs in A4 are unmarked 
3: generate the initial and the final nodes no and Vf in G 
4; for each pair Mi, M 2 € M do 

5: if Ml and M 2 infers an MSC M to be repetitive within a context Mp-Ms then 

6: mark both Mi and M 2 

7: if M is while-repetitive then 

8: generate a new path p in G given below, where n is a new node 

p = {(no, Mp,v), (v, M, v), (n, M„, n/)} 

9: else 

10: generate a new path p in G given below, where v and v' are new nodes 

p = {(no, Mp,v), (v, M, v'), (n', M, n'), (n', Ms,Vf)} 

11: end if 

12: let src(p) = {Ml, M 2 } 

13: end if 

14: end for 

15: for each unmarked MSC M do 

16: generate a new path p = {(no, M, n/)} 

17: let src{p) = {M} 

18: end for 

19: /* phase 2: merge paths and form G' */ 

20: let G' be an empty graph 

21: obtain a partition 77 of the set of paths such that two paths p,p' are in the same 
subset P of 77 iff 3 a sequence of paths pi,p 2 , ■ ■ ■ ,pk where Pj (z P, 1 < j < k, 
p = pi, p = Pk, and for 1 < i < fc, src(pi) Pi src(p i+l) / 0 
22: for all P £ U do 
23: insert merge{P) into G' 

24: end for 

Fig. 4. Algorithm 2 - Building the MSC graph based on a set of MSCs A4 



Hence, the for loop at lines 22-24 in Algorithm 2 will iterate only once, and will 
insert the merging of Md and Mg into G'. 

In Algorithm 3, we consider every path as a set of three edges : (no, Mp, m), 
(v\,M, m) and {vi,Mg, Vf). Mp, M and Ms will be referred to as the prefix, loop 
and the suffix labels of the path, respectively. Note that, if the path is generated 
for a repeat repetitive subfunctionality, then we consider the first iteration of 
the loop as embedded in the prefix label. 

Note that, G' produced by the second phase will effectively have the loops 
in G placed in their relative order, which also includes placing a loop into another, 
i.e. nesting of the loops. Deciding the relative orders of the loops in different 
paths in the merged path is based on having a common observation used in the 
generation of these paths. For instance, see the example given above. 

Note that. Algorithm 3 depends on tracing MpMg on the path pm (which 
is actually an MSC graph) accumulated so far. Given an MSC M and an MSC 
graph G, it is known that deciding if M G L{G) is NP-complete [8, 19]. For- 
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1: let p be a path in P whose prefix label is the shortest among other paths in P 

2: let Pm =p 

3: let src{pm) = src{p) 

4: let P = P — {p} 

5: while P is not empty do 

6: let p be a path in P such that src{p) O srcijpm) 7 ^ 0 and the prefix label of p is 

the shortest among other such paths in P. 

7: src{pm) = src{pm) U src{p) 

8: P = P - {p} 

9: trace the concatenation of the prefix label Mp and the suffix label Ms of p in p„i 

(by skipping e edges) 

10: if during this trace Mp ends in the middle of an edge in pm then 

11: insert a new node v in the middle of that edge in pm 

12: insert a new edge (v, M, v) in pm where M is the loop label of p 

13: else 

14: let V be the node at which the trace of Mp has ended 

15: if during the trace of Mp, v is visited exactly once then 

16: insert a new edge (v, M, u) in pm where M is the loop label of p 

17: else 

18: let (v, M' ,v') be the edge which is not used during the trace of Mp 

19: remove the edge (v, M' , v') 

20: insert a new node v" in pm 

21: insert a new edge (v" , M' ,v') 

22: insert a new edge (v, e, v") 

23: insert a new edge (v" ,M,v”) 

24: end if 

25: end if 

26: end while 
27: return [pm) 

Fig. 5. Algorithm 3 - Merging paths in a partition P 



tunately, in principle, tracing of MpMg on pm corresponds to the case given in 
Theorem 6 of [8] with a time complexity of 0{\pm\ x \MpMs\). 

5 Conclusion 

We have presented an algorithm to derive an MSC graph G' from a given set 
of observations of an existing implementation of a concurrent system. This al- 
gorithm is based on inferring repetitive subfunctions from a given set of obser- 
vations. The language of the MSC graph G' derived consists of all the given 
observations and the inferred observations, in which the loops and their rela- 
tive positions are all explored. And thus, the language of the MSC graph G' is 
a design representation of the existing system. 

An interesting problem that remains open is the following. When the ev- 
idences of some loops are missing in the given set of observations, generated 
subgraphs may provide these missing evidences. For example, assume that ini- 
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tially we have three MSCs Ma = M^M^, Mb = 

and Me = M\M^M^^^ M^- Ma and Mb infers M 4 to be while-repetitive within 
the context MiM^^^ M^-M^. Hence Md = M\M!f^ M^M^M^ is generated. Al- 
though Me does not infer any repetitive subfunctionality with Ma or Mb, it 
infers M 2 to be while-repetitive within the context M\-M^Mi M 5 when it is 
considered together with Me = MiM!^'' M^M f’'* Mr, which is obtained by in- 
stantiating * by 3 in Md- However, these new repetitive subfunctions must be 
confirmed by the observer. Hence the question is, can and how an MSC graph, 
which is a design representation of the existing system, be generated under such 
missing evidences. 

It will also be interesting to consider the effects of a) the number of occur- 
rences of repetitive subfunctions in the given set of observations to be a fixed 
value, and b) some apriori knowledge of the structure of the communicating 
processes on the derivation of an MSC graph. 
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Abstract. Passive testing has proved to be a powerful technique for pro- 
tocol system fault detection by observing its input /output behaviors yet 
without interrupting its normal operations. To improve the fault detec- 
tion capabilities we propose a backward checking method that analyzes 
in a backward fashion the input/output trace from passive testing and its 
past. It effectively checks both the control and data portion of a protocol 
system, compliments the forward checking approaches, and detects more 
errors. We present our algorithm, study its termination and complexity, 
and report experiment results on the protocol SCP. 



1 Introduction 

Passive testing is an activity of detecting faults in a system under test by ob- 
serving its input/output behaviors without interfering its normal operations. The 
usual approach of passive testing consists in recording the trace produced by the 
implementation under test and trying to find a fault by comparing this trace 
with the specification ([4], [6], [7]). Other approaches explore relevant properties 
required for a correct implementation, and then check on the implementation 
traces of the systems under test ([1], [2]). Most of the work on passive testing 
are based on finite state machines (FSMs) and they are focused on the con- 
trol part of the tested systems without taking into account data parts. To cope 
with protocol data portions. Extended Finite State Machines (EFSMs) are used 
to model the systems, which include parameters and variables to encode data. 
In [7] a first approach to perform passive testing on EFSMs was proposed. An 
algorithm based on constraints on variables was developed and applied to GSM- 
MAP protocol. However, this algorithm cannot detect transfer errors. In [5], an 
algorithm based on variable determination with the constraints on variables was 
presented. This algorithm allows to trace the variables values as well as the sys- 
tem state, however, every transfer errors still cannot be detected. 

To overcome this limitation, we propose a new approach based on backward trac- 
ing. This algorithm is strongly inspired by this presented in [-5], but processes 
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the trace backward in order to further narrow down the possible configurations 
for the beginning of the trace and to continue the exploration in the past of 
the trace with the help of the specification. This algorithm contains two phases. 
It first follows a given trace backward, from the current configuration to a set 
of starting ones, according to the specification. The goal is to find the possible 
starting configurations of the trace, which leads to the current configuration. 
Then it analyses the past of this set of starting configurations, also in a back- 
ward manner, seeking for end configurations, that is to say configurations in 
which the variables are determined. When such configurations are reached, we 
can take a decision on the validity of the studied path. 

This new algorithm is applied to Simple Connection Protocol (SCP) that allows 
to connect two entities after a negotiation of the quality of service required for 
the connection. Even it is a simple protocol it presents a number of key char- 
acteristics of real communication protocols. The testing results are compared to 
the passive testing algorithm in [5]. 

The rest of the paper is organized as follows. Section 2 describes the basic con- 
cepts used in the paper. Section 3 contains preliminary algorithms for processing 
transition back tracing. The section 4 presents the main backward tracing al- 
gorithm. In section 5 the issues related to the termination and complexity of 
the main algorithms are discussed. Section 6 reports the experiments of the 
algorithm on the Simple Connection Protocol. 

2 Preliminaries 

We first introduce basic concepts needed and then present an overview of our 
algorithm. 

2.1 Extended Finite State Machine 

We use Extended Finite State Machine (EFSM) to model the protocol systems. 

Definition 1. An Extended Finite State Machine M is a 6-tuple M =< S, sq, /, 
0,x,T > where S is a finite set of states, sq is the initial state, I is a fi- 
nite set of input symbols (eventually with parameters), O is a finite set of out- 
put symbols (eventually with parameters), x is a vector denoting a finite set 
of variables, and T is a finite set of transitions. A transition t is a 6-tuple 
t =< Si, Sf ,i,o, P, A > where Si and Sf are the initial and final state of the 
transition, i and o are the input and the output, P is the predicate (a boolean 
expression), and A is the ordered set (sequence) of actions. 

Definition 2. An events trace is a sequence of I/O pairs. 

In this paper we consider that the traces can start at any moment of the 
implementation execution. 

Given a trace from the implementation under test and a specification, the 
algorithm will detect the three types of error that can occur in an EFSM. 
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Fig. 1. Output(l), transfer(2), and mixed(3) errors 




Fig. 2. Overview of Backward Checking 



Definition 3. The three types of error are: 

1. the output errors: when the output of a transition in the implementation 
differs from the output of the corresponding transition in the specification. 

2. the transfer errors: when the ending state of a transition in the imple- 
mentation differs from the ending state of the corresponding transition in 
the specification. 

3. the mixed errors: a mix between the two errors defined above. 



2.2 Candidate Configuration Set 

The backward checking algorithm processes in two phases as shown in figure 2. 
The first step consists in following the trace w backward, from the end to the 
beginning, according to the specification. The goal is to arrive to the set X of 
possible start configurations of w. In order to keep information we use configu- 
rations named Candidate Configuration Set (CCS) inspired from [-j]. 

Definition 4. Let M be an EFSM. A Candidate Configuration Set (CCS), is 
a 3-tuple {e, R, Assert) where e is a state of M, R is an environment (that is 
to say that each variable v has a constraint R{v) ), and Assert is an assertion 
(Boolean expression). 

The second step is the backward checking of the trace past. This step consists 
in confirming at least one of the departure configurations extracted from the back 
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tracing of a trace. It means we must verify that the variable values or constraints 
are compliant with the specification. We need to trace the transitions from their 
end states to their start states until we reach a validation criteria. We need to 
confirm the variables ranges. However, often there is only a subset of variables 
that we can confirm, and we call these variables determinant of a trace. 

Definition 5. A variable v is a determinant of a trace t if v must he necessarily 
validated before validating t. 

In order to keep information about determinants, we define a new structure 
for the past of the trace: the Extended Candidate Configuration Set (also called 
Extended Configuration) . 

Definition 6. Let M be an EFSM. An Extended Candidate Configuration Set 
(ECCS) is a 4-tuple {e, R, Assert, D), where e is a state of M , R is an environ- 
ment, Assert is an assertion, and D is a set of determinant variables. 

Between the two steps we check the determinant variable set as follows: 
every variable whose interval in a configuration of X - the set of possible start 
configurations of the trace that is included in its specified domain - must be 
added to the determinant variables set to be checked. 

3 Preliminary Algorithms 

In the following section, we present the preliminary algorithms that will be used 
in the main algorithm. We begin with the inverse actions algorithm, and then 
consistency checking and the transition back tracing algorithms. 

What we do is checking backward the trace and then exploring its past as shown 
in Fig 2, determining the variables. In order to perform this checking on the 
whole trace and its past we need a process that checks a transition backward. 
The algorithms presented in this section make it possible. 



3.1 The Inversed Actions 

A main difficulty is the application of the inverse action A~^. The inverse actions 
will be processed in a reversed order. Hence the following normal ordered actions 
{oi, . . . , On} will be processed in an order: {a „, . . . , oi}. 

Each inverse action depends on the type of the corresponding normal action. 
There are three types of actions: 

1 . w < — constant 

2. w < — f{u, V, . . .) where w is not a variable of / 

3. w < — f{w, u,v, . . .) where w is also a variable of / 

These three types of actions are assignations: they overwrite the value of the 
left variable w with the value of the right component. We note that the value 
of w is modified by an action, but the other variables after action keep the value 
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they had before the action and that only the value of the variable w will be 
modified by back tracing a transition. Except for this, every type of action must 
be inverted: 

1. Action of type 1. The value of w after the action is a constant. This gives 
us a first occasion of detecting an error. If the constant does not conform 
the current constraint then we are on an invalid path. Otherwise, we replace 
every occurrence of w with the constant and refine the constraints of other 
variables. However, it is impossible to know the value of w before the action; 
indeed, actions simply overwrite the former value of w. After the action back 
tracing the value of w is UNDEFINED; 

2. Action of type 2. We could take that R{w) is equal to R{f{u, v , . . .)) but we 
can be more precise: it is R{w) n R{f{u,v , . . .)). In order to keep as much 
information as possible, every occurrence of w will be replaced by /(rt, v, . . .). 
However, the value of w before action remains UNDEFINED; 

3. Action type 3. This action brings no new constraint refinement on the vari- 
able w (on the left side of the assignment) after the action (left member) 
but it gives a constraint on the variable w (on the right side of the assign- 
ment) before the action. Consequently, every occurrence of w will be replaced 
by /"^(w)- 



3.2 Final Checking Phase 

The check_consistency process is from [5] and is able to detect inconsistency 
in the definition of the variables by refining the intervals of variables and its 
constraints. 

There are no big differences between the transition back tracing algorithms for 
the trace and for its past, and we ignore in the trace algorithm what can happen 
to the set of determinants before the action. Indeed, in the trace we do not 
determine variables; we can only refine their values, and we invalid the trace if 
the constraints are not consistent. For the trace we must check the output before 
processing the inverse actions. After processing every action we can determine 
the variables involved in the input if its constraint is consistent with what we 
found. Otherwise, we invalid the transition. 

On the other hand, we must check that the variable values that we found are 
consistent with the predicates. Otherwise, the path is invalid. Therefore, in the 
checking we must determine if a transition is valid or not. We need a process 
called check_pred for the past of the trace to modify the set of determinants. 
In the case of back tracing, we just need to add the predicates to the set of 
assertions and process check_consistency - no specific operations are needed. 
The pseudo code for back tracing of the trace and of its past, followed by the 
check_pred and check_consistency algorithms are presented in the appendix. 
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3.3 Example 

We show now an example of this process. Consider the common steps of the trace 
and past cases, a transition without input/output, and we include the variable 
set D into parentheses. 



Starting point 


1 P : u>=l 




A : x=l 

y=y+l 

z=v+w R=<U [0;3] , X [1;4] , 

y [2;8] , z [1;2] , a [7;9] , 

[ i ] f ] V undef , w undef > 

V / V / Asrt = - 

(D = {u,x, y, z, a} ) 


After inversed actions 


1 P : u>=l 


R = < u [0;3] , a [7;9] , 
y [1;7] , cste [1;2] , 

v,w undef , 
x,z undef > 

Asrt - {v+w=cste} 

(D = {u, a,y , V, w} ) 


A : x=l 

y=y+l 

z=v+w R = < u [0;3] , X [1;1] , 

y [2;8] , z [1;2] , a [7;9] , 

(D = {u,x, y, z, a} ) 


After check pred 


1 P : u>=l 


R = < a [7;9] , y [1;7] , 
u [1;3] , cste[l;2] , 
v,w undef , 
x,z undef > 

Asrt - {v+w=cste} 

(D = {u, a, y, V, w} ) 


A : x=l 

y=y+l 

z=v+w R— <u [0;3] , X [1;1] , 

y [2;8] , z [1;2] , a [7;9] , 

f i j f 1 v,w undef > 

Asrt = - 

(D = {u, X, y, z , a} ) 



4 Main Algorithms 

We are ready to present our main algorithm of backward checking. 

4.1 Backward Checking of a Trace 

The backward checking for a whole trace can be derived from the algorithm for 
back tracing a transition (Back_trace_transition): 

- trace: The observed trace. gettail{trace) removes and returns the last i/o 
pair from trace. 

- X\ Set of starting extended configurations from back trace of an event trace. 
Each configuration is a 4-tuple (e, R, Assert, D) 

- X': Current set of extended configurations 

- V : Set of known extended configurations 

- c': A new configuration 

- : Returns TRUE if the sequence is correct, and FALSE otherwise 
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1. V < — A 

2. while 

A 7 ^ 0 & i/o gettail (trace) do 

3. .A' « — 0 

4. .for each configuration c € A do 

5. . .for each transition t where 
t.end^state = estate and 

t.i/o — ijo do 



6 . . . 

.c' < — Back_trace_transition(t, c) 

7. . . .A'« — A'u{c'} 

8. ...!/« — VVJX' 

9. .A « — A' 

10. return FALSE 



4.2 Backward Checking of the Past of an Event Trace 

The backward checking algorithm applied to the past of a trace consists of 
a breadth-first search in the past of the configurations, which are extracted from 
the back tracing of a trace due to the fact that one cannot use a variable value 
before it is assigned. In order to validate a trace, we only need to find a path 
binding a set of assignments or predicates to one of the configurations extracted 
from back tracing. We now proceed to the main algorithm. We first define the 
operations □ and \ on the Extended Candidate Configuration Sets (ECCS) that 
will be used for pruning the exploration tree of the past. Then we study the 
path convergence and discuss the algorithm termination, the correctness and 
the complexity. 



The n Operation. It is an intersection between two configurations: 

Definition 7. Let he three configurations ci = (e, Ri, Asserti, D), C2 = (e,i? 2 , 
Assert2, D), and c = (e, i?, Assert, D). We define the intersection operator □ as 
follows, //c = Cl n C2, then: 

1 . for each variable v, R(v) = Ri(v)nR2(v) where C is the intervals intersection 
operator 

2 . Assert = Asserti A Assert2 where A is the boolean “and” operator 

Remark on □. The configuration states and the variable sets, which are not 
validated yet, are the same. If they are not, the “intersection” equals to NULL. 



The \ Operation. It is a privation. Given two configurations ci and C2, the 
result of ci\c2 is a couple (ca,Cb). We obtain Ca by removing C2 from ci, but 
only in case of each variable is restricted to the intersection of the intervals ci 
and C2, respectively. Cb is the rest of ci. 

Definition 8. Given four configurations ci = (e,R\, Asserti, D), C 2 = (e,i? 2 , 
Assert2,D), Ca = (e, Ra, Asserta, D) and Cb = (e, Rb, Assertb, D), we define the 
privation operator \ as follows. If (ca,Cb) = Ci\c2, then: 

1 . for Ca: 

(a) for each variable v, we have got: Ra(v) = Ri(v) H R2(v) where C is the 
intervals intersection operator 
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(b) Assert a = Asserti A Assert 2 , where A is the boolean “and” operator 
2. for Cb: 

(a) Rb = Ri 

\v\-i 

(b) Assertb = Asserti A ( \J {vi ^ R 2 {vi))) where A is the boolean “and” 

i=0 

operator, and V is the boolean “or” operator ( be careful of priorities of 
parenthesis ) 

Remark on \ . If Assert 2 equals to 0, then Ca equals to NULL. Indeed Assert 2 
means we have to keep all of the values that i ?2 allows, yet on the contrary 
Assert 2 implies that we must delete all of them. 

General remark. The operations n and \ may return configurations, which are 
inconsistent. For example, the result of ci\ci is not consistent. Moreover, some 
results may need to be refined. Indeed when two assertions are concatenated 
the constraints intervals of each variable may have to be changed. So we should 
use the Check_consistency procedure that has already been presented. For 
now, we consider that the results of □ and \ are automatically checked and 
transformed by Check_consistency. 

Examples. Consider the configurations ci = (e, < a; = [0; 5],y = [0; 3] >, _, {x}) 
(where _ means no assertion) and C 2 = (e, < x = [0;2],?/ = [— 1;1] >,{x > 
y}, {a;}), and three configurations Ci, Ca and Cf,, which are defined as following: 

- Ci = Cl n C2 
(Oa,C^) Ci\c2 

We first determinate Ci. Ri is defined as the intersection of Ri and i? 2 , and 
Asserti is Asserti A Assert 2 - Then we have: 

Ci = {e,<x= [0;2],i/ = [0; l],{x > 2 /},{a:}). 

Determinating Ca and Cf, is a little bit more complicated. Ra is the intersec- 
tion of Ri and i? 2 , and Asserta is Asserti A Assert 2 - Then we have: 

Ca = (e, < a: = [0; 2], y = [0; 1] >, {a; < y}, {a:}). 

At last for Cb, we have the following properties. Rb equals Ri, and we must 
add a: < 0 V a: > 2 and y<0Vj/>lto Assertb- Then we have: 

Cb = (e, < a; = [0; 5], y = [0; 3] >, {(a: < 0 V a; > 2) A (y < 0 V y > 1)}, {a;}). 

Note that the two last configurations Cq and Cb are not refined as it was de- 
fined in [5]. If we apply the Check_consistency procedure, we obtain: 

Ca = {e,< x = [0;l],y = [0; 1] >,{x < y},{a:}) and Cb = (e,< x = [3;5],y = 
[2; 3] >,., {x}). 

Path Convergence. Consider a step r of our algorithm. If we find a configu- 
ration c that we have already found earlier, in a previous step or earlier in the 
step r, we have got a “path convergence” phenomena. 
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Fig. 3. Example of Path Convergence 



Definition 9. Two paths P\ and P2 are convergent (in the past!) if they lead to 
the same configuration c. 

Consequently both P\ and P2 have the same past. So we will obtain the same 
information if we explore the common past from P\ or from P2- Consider that 
we have first followed P\ . When we find that P2 converges toward c, we do not 
continue the exploration: we prune P2 at c. The pruning enables us to deal with 
the infinite exploration paths. 

Unfortunately extended configurations make convergences hard to be detected; 
they are non-empty intersections of configurations. We proceed as follows. Given 
three configurations c, ci and C2, let c be equal to ci □ C2. Suppose that C2 has 
been found before ci. Then we have the following: 

— c =NULL. Cl and C2 are independent and the respective pasts of ci and C2 

must be explored; 

— (c yfNULL) A (c = Cl). Cl is included in C2 and we must delete ci; 

— (c yfNULL)A(c yf ci). C2 is included in ci and we must substitute ci by ci\c2 

The algorithm Check_redundancy, that will be described later, deals with 
the convergence cases. 

Algorithm of Backward Checking of the Past of a Trace. The Back- 
ward_checking_past algorithm backward traces the past of a trace in order to 
validate it. The input is the set of starting extended configurations, which we 
extracted from the trace back tracing. 

Note that if the start configuration is invalid (not reachable from the initial 
configuration set) then we have to explore backward all the configurations to tell 
whether there is no valid path from the initial configuration set. However, if it 
is indeed valid, finding a valid path is enough. In most cases of passive testing, 
the traces do not contain faults and it is desirable to use a heuristic method to 
find a valid path. We now present such a procedure. 

In order to guide the heuristic search, we have figure out the end configura- 
tions. A configuration set c is an end configuration set if it satisfies one of the 
following conditions: 

1 . c D cjinit yf 0 where cjinit is the initial configuration set of the machine 

2 . c.D = 0 

3 . c is contained in another configuration set that has been explored 
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The second criteria is valid, since c. state is reachable from the initial state 
of the machine, and there must be a valid path from the initial configuration. 

We now present a heuristic search. We assign a weight for each configuration- 
transition pair < c,t>. Since we want to trace back to the initial configuration 
or reduce c.D, we increase the weight of such pairs. A priority queue Q contains 
all the configuration-transition pairs to be explored, sorted by their weights. The 
pair with the highest weight is placed in the head of Q and will be selected first. 

The weight wgt of a configuration-transition pair < c,t > with an initial 
value 0 can be incremented by the following rules: 

1. if t.start-state = cJnit. state, wgt -|-= rcl 

2. if t. start state has not been explored, wgt += w2 

3. if t.action defines k variables in c.D, wgt += w3 * k 

The first two rules guide the search towards the initial state of the specifica- 
tion while the third one is to reduce the set of determinants. It is important to 
remark that we don’t need to reach the initial state itself, and that a transition 
determining every variables left in the set of determinants is enough to conclude 
on the correctness of the explored path. This explains the importance of the 
third rule (we can note that the initial state is a particular case of it as it is 
supposed to determine every variables). 

The values of wl,w2, and w3 can be given after practical usage. 

The following is the procedure where 

- Q: Set of configuration-transition pairs to be explored 

- V : Set of already-explored Extended Configurations 

- : Returns TRUE if the trace is correct, and FALSE otherwise. 



1. initialize Q,V 

2. while <5 7 ^ 0 do 

3. .take the first item < c,t > 
from Q 

4. .build a new configuration cb 

d « — Back_past_transition(t, c) 

5. .ii d NULL 

6. . .goto 2 

7. .ifc'.U = 0do 

8. . .return TRUE 



9. .d =Check_redundancy(c^ V) 

10. .If c' / 0 do 

11. . .U« — UUc' 

12. . .for each transition t where 
t.endstate = d .state do 

13. . . .calculate the weight of 

< d ,t > 

14. . . .insert < d ,t > into Q by 

its weight 

15. return FALSE 



In the worst case, this algorithm will explore backward all the possible con- 
figurations. When Q becomes empty no valid path is possible from the trace 
information from the passive testing and “FALSE” is returned - there are faults 
in the protocol system under test. 
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5 Algorithm Termination and Complexity 

In the first part of the algorithm (backtracking of the trace) there is no problem 
of termination because we follow the trace, so this step finishes when the trace 
finishes. The problem we had and we solved is in the second part of the algorithm 
(in the past of the trace). We present these problems in the following subsection. 

5.1 Loop Termination 

There are two problems that we must solve: infinite paths, and infinite number 
of paths. These problems are often caused by loops. 

A first infinite path case occurs when a path infinitely often reachs a configura- 
tion. This problem is solved thanks to the detection of path convergence (see 4.2), 
and ECCS operations that prevents exploring more than once in a configuration. 
A second case occurs when a variable is infinitely increased or decreased. In this 
case the loop is limited by the upper or lower bound of the interval of definition 
of the variable. 

There are two cases when we have an infinite number of paths. First, a con- 
figuration has an infinite number of parents. Secondly there is an infinite path 
from which several paths start. But if the configurations number is finite, then 
a configuration can not have an infinite number of parents. 

We proved the termination of the algorithm, and we present in the next subsec- 
tion a study of the algorithm complexity. 

5.2 Complexity 

In the first part of the algorithm (trace) the complexity depends on the trace. 
We have: 



Proposition 1. Suppose that the observed event trace is of length /, then the 
complexity of the first part of the presented algorithm is proportional to 1. 

For the second part (past of the trace) the complexity depends on the number 
of possible configurations. A configuration includes a state number, interval of 
definition of variables, and a list of determinant variables. The complexity of the 
second part of the algorithm is: 



Proposition 2. Let Ug be the number of states in the FFSM of the specification, 
|i?(a;i)| the number of values the variable Xi can take (in the interval of defini- 
tion), and n the number of variables, then there is in 0(71^(11^ l^(3;i)l)(2"' — 1)) 
possible configurations. 

We must balance this complexity with the power of the algorithm. The worst 
case of this algorithm is the case where there is an error because we must check 
every path of the past. When there is no error our algorithm gives a sure answer 
(in constrast with former algorithms) at the first correct path we meet (that is 
supposed to be fast using the heuristic) . Anyway, the backward checking - if we 
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Fig. 4. Simple Connection Protocol: Layers 



consider only the trace analysis - is an improvement of former algorithm, and 
has the same complexity. 

6 Experiments on SCP Protocol 

We now report the application of our algorithms on the Simple Connection 
Protocol (SCP). SCP is a very interesting protocol for test purpose because 
it includes most possible difficulties for passive testing in a small specification. 
Therefore, it can show the efficiency of the algorithm on bigger real protocols. 
We first describe this protocol and then report the experiments of the algorithm 
from [-5] and our new algorithm. 

6.1 The Simple Connection Protocol 

SCP allows us to connect an entity called upper layer to an entity called lower 
layer (Fig 4). The upper layer performs a dialogue with SCP to fix the quality 
of service desirable for the future connection. Once this negotiation finished, 
SCP dialogues with the lower layer to ask for the establishment of a connection 
satisfying the quality of service previously negotiated. The lower layer accepts 
or refuses this connection request. If it accepts the connection, SCP informs the 
upper layer that connection was established and the upper layer can start to 
transit data towards the lower layer via SCP. Once the transmission of the data 
finished, the upper layer sends a message to close the connection. On the other 
hand, if the lower layer refuses the connection, the system allows SCP to make 
three requests before informing the upper layer that the connection attempts 
all failed. If the upper layer wishes again to be connected to the lower layer, 
it is necessary to restart the QoS negotiation with SCP from beginning. Every 
variable is defined in the interval [0; 3]. An EFSM specification of SCP is in the 
figure 5. 

6.2 Experiments of the Two Algorithms 

Consider a false implementation of SCP, that has been used in [2]: the pred- 
icate of the transition @ is replaced by TryCount = 0. The fig- 
ures 6, 7 and 8 show the executions of the first algorithm and of the backward 
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Try Count := 0 
ReqQos : = 0 
FinQos : = 0 



I/O : CONreq (qos) /NONsupport (ReqQos) 
P : CONreq. qos > 1 
A : ReqQos := CONreq. qos 



I/O : CONreq (qos) /connect (ReqQos) 
P : CONreq. qos <= 1 
A : ReqQos := CONreq. qos 



I/O : refuse/connect (ReqQos) 
P : TryCount ! = 2 
A : TryCount : = TryCount + 1 



I/O : accept (qos) /CONcnf (+, FinQos) 

P : - 

A : FinQos := min (accept . qos , ReqQos) 



I/O : Data/data (FinQos) 



Fig. 5. Simple Connection Protocol: EFMS specification 



checking algorithm (trace and past) on the trace CONreq(l)/ connect(l), 
refuse /CON cnf(- ) . 

The figure 6 shows that the error is not detected by the algorithm presented 
in [5]. The trace is left ’’possible” for it. 

The figure 8 shows the execution of backward checking algorithm in the past. 
We obtain the configuration (5'2, < TryCount = 2] ReqQos = 1; FinQos = 
[0; 3]; CONreq.qos = !>,_, {TryCount; ReqQos; CONreq.qos}) from the back 
tracing of the trace (Fig. 7) and we continue in the past. After the first step of 
the while loop, X is empty because the transition @ — leads to a contradic- 
tion between CONreq.qos value (=1) and the predicate CONreq.qos > 1, and 
the transition @ is also invalid due to a contradiction between ReqQos 
value (=1) and the action ReqQos = 0. Then there is no more configuration to 
backtrack and the algorithm terminates, returning FALSE - there are faults in 
the protocol implementation. 

7 Conclusion 

Apparently, passive testing is a promising method for protocol fault manage- 
ment, as it allows to test without disturbing the normal operation of a protocol 
system or service. In this paper, we present a new backward checking algorithm. 
It detects output and transfer errors in an implementation by observing and 
analyzing its event traces. A major difficulty of passive testing is its analysis for 
faults. Our approach provides a backward trace analysis that is efficient and also 
a compliment to the forward analysis in [5], and can uncover more faults. 
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step 


event 


configurations 


0 




{Si-, <TC= [0; 3], 7?Q = [0; 3], FQ = [0; 3], Crq.qos = 
[0; 3], acc.qos = [0; 3] >, _) 

(for each i state number) 


1 


CONreq(l) / con- 
nect (1) 


{S3; <TC= [0; 3], RQ = l,FQ = [0; 3], Crq.qos = 1, 
acc.qos = [0; 3] >, _) 


2 


refuse / CONcnf(-) 


{Si; < TC = 2, RQ = 1, FQ = [0;3], Crq.qos = 1, 
acc.qos = [0; 3] >, _) 



Fig. 6. Execution of the First Algorithm 



step 


event 


configurations 


0 




(S,; <TC= [0; 3], RQ = [0; 3], FQ = [0; 3], Crq.qos = 
[0; 3], acc.qos = [0; 3] >, _) 

(for each i state number) 


1 


refuse / CONcnf(-) 


{S3; < TC = 2, RQ ^ [0;3], FQ = [0;3], Crq.qos = 
[0; 3], acc.qos = [0; 3] >, _) 


2 


CONreq(l) / con- 
nect (1) 


{S2; <TC = 2, RQ = 1, FQ = [0;3], Crq.qos = 1, 
acc.qos = [0; 3] >, _) 



Fig. 7. Back Tracing the Trace 



step 




0 


current 

conf. 


{S 2 , <TC = 2; RQ = 1; FQ = [0; 3); Crq.qos = !>,_, {TC',RQ; 

Crq.qos}) 


seen 

conf. 


{S 2 , <TC = 2; RQ = 1; FQ = [0; 3); Crq.qos = !>,_, {TC',RQ; 

Crq.qos}) 


transition 

©< — © 
transition 

©< — @ 


back 

tracing 


next 

config. 


0 


back 

tracing 


next 

config. 


0 


validation 


there is no more configuration: return FALSE 



Fig. 8. Back Tracing the Past of the Trace 



Passive testing is a formal approach for network protocol system monitoring 
and measurement where Internet protocols such as OSPF and BGP were mon- 
itored for fault detection [3]. Formal method will continue to exhibit its power 
in network protocol system fault management in a wider range of applications 
and protocol layers. 

8 Appendix 

Back_trace_transition(t,c) Algorithm 

This algorithm is used for backtracing a transition during the trace processing. 
- : returns c' if c' — ^ c is possible, NULL if not. 
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1. if {output.v ^ c.R{v)) do 

2. .return NULL 

3. else 

4. .c' = clone{c) 

5. .c' .R{v) — Defiv) 

6. .replace every occurrence of v in 
c' .Asrt by 

output.v 

7. inverse list of actions 

8. foreach action a do 

9. .if action a is: w « — constante 

then 

10. . .if c' .R{w) n constante = 0 

then 

11. . . .return incorrect trace 

12. . .else 

13. . . .c' ,R{w) = Def{w) 

14. . . .replace every occurrence of 

w in c' .Asrt by constante 

15. .if action a is: w < — /(®) then 



16. . .replace every occurrence of w 
by 

f(x) in c' .Asrt 

17. . .if w e X then 

18. . . .c' .R{w) = R{f-\x)) 

19. . .else 

20. . . .c' .Asrt = c' .Asrt A 

{w < f{x) < W) 

21. . . .c' .R{w) = Def{w) 

22. foreach predicate p do 

23. .normalize p 

24. .c' .Asrt = c' .Asrt A p 

25. if {input.v ^ c' .R{v j) do 

26. .return NULL 

27. else 

28. .c' .R{v) = Defiv) 

29. .replace every occurrence of v by 

input.v in c' .Asrt 

30. check_consistency(c') 

31. return c' 



Back_past_transition(t,c) Algorithm 

This algorithm is used for backtracing a transition during the past trace pro- 
cessing. 



1. c' = clone(c) 

2. inverse list of actions 

3. foreach action a do 

4. .if action a is: w < — constante 

then 

5. . .if c' .R{w) n constante = 0 

then 

6. . . .return incorrect trace 

7. . .else 

8. . . .c' .R{w) — Def[w) 

9. . . .replace every occurrence of 

w in c' .Asrt by constante 

10. . . .D = D — w / /w is 

validated 

11. .if action a is: w < — f(x) then 



12. . .replace every occurrence of w 
by 

f(x) in c' .Asrt 

13. . .if w G X then 

14. . . .c' .R{w) = R{f-\x)) 

15. . .else 

16. . . .D = D — w 

17. . . .c' .Asrt = c' .Asrt A 

(w — cst < f{x) <w — cst) 

18. . . .c' .R{w) = Def{w) 

19. . .D — D yj y 

20. check_consistency(c’) 

21. check_pred(p,c’) 

22. return c' 



Check_pred(P, c) Algorithm 



1. for each predicate v = f{x) G P 


3. . .c.D = c.D — V // V is 


do 


validated 




4. . .c.R{v) = c.R{v) n c.i?(/(x)) 


2. .if ic.R{v) n c.R{f{x)) C c.R{v)) 


5. .else return FALSE 


then 


6. return TRUE 
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Check_consistency(c) Algorithm 

The following algorithm derives from the one presented in [5]. It tests configu- 
rations consistency, refines their constraints and delete all unused assertions. It 
returns the processed configuration if the initial one is consistent, or NULL if it 
is not. 

Variable assignment Rule (R): for each variable range if we have a set of 
non empty intervals from the processing of the conjunctive terms then the new 
variable range consists of an interval whose lower (upper) bound is the minimum 
(maximum) of all the interval lower (upper) bounds. 

- c: configuration that must be refined 

- c': copy of c. Note c' = {e, R, Assert, D) 

- return the refinment of c, or NULL 

- S': a new set of intervals 

- At. a, new assertion 



1. c' < — c 

2. transform d .Assert in DNF 
i. S < — 0 

4. At< — 0 

5. for each conjunctive term Dt of 
c' .Assert do 

6. .dtArue < — TRUE 

7. .refine < — TRUE 

8. .while refine = TRUE do 

9. . .refine < — FALSE 

10. . .Ri < — d.R 

11. . .R[< — 0 

12. . .for each predicate p of Dt do 

13. . . .normalize p 

14. . . .ifX)i(aiAi(a;i)) CR(~^) 

do 

/*p is TRUE*/ 

15 remove p from Dt 

16 go to 12 

17. . . .if 

'Y^.{aiRi{xi)) n R(~ Z) = 0 then 

18 dtJtrue < — FALSE 

19 go to 28 

20. . . .for each Xj , j = 1, . . . , k 

do 



21 . 



22 . 

23. 

24. 

25. 

26. 

27. 

28. 

29. 

30. 

31. 

32. 

33. 



34. 

35. 

36. 

37. 

38. 

39. 



■R’lixj) 






nRl (Xj) 

.if R'lixj) = NULL do 
.dtJtrue < — FALSE 

.go to 35 

.if R[{xj) C Ri{xj) do 
.refine < — TRUE 

< — R'lixj) 

.if dtJtrue = FALSE then 
.remove Dt from d .Assert 
.else 

.for each variable v do 
. .At < — At A {v G Ri{r)) 

. .S{v) < — combination of 

S{v) and 

Ri{v), 



according to R 
if |S| = 0 do 

.return NULL 
else 



.d.R < — S 

.d .Assert < — d .Assert A At 

.return d 



Check_redundancy(c, V) Algorithm 

The following algorithm aims to deal with convergence cases, in order to solve 
the infinite loops problem. 

- c: configuration to be checked 

- V : set of already-seen configurations 

- X : set of configurations from redundancy check 

- X': intermediate set of configurations 
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1. A ^ {c} 


10. 


. .goto 4 


2. for each configuration cv (zV do 


11. 


. .else if (c( 7 ^NULL)&(c' ^ a) 


1 

CO 




do 


4. .for each configuration d £ X do 


12. 


• • •(c,“,Ci)< — Ci\c' 


5. . .c'i < — Ci n cv 


13. 


. . .ifc“/NULLdo 


6. . .if c'i =NULL do 


14. 


. . . .A'. — A'u{c“} 


7. . .X'^X'\J{ci} 


15. 


. . .if c\ t^NULL do 


8. . . .goto 4 


16. 


. . . .A'^A'U{4} 


9. . .else if (c' t^NULL)&(c( = a) 


17. 


.A « — A' 


do 


18. 


return A 
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Abstract. In this paper we show how to automatically generate test 
sequences that are aimed at testing the interconnections of embedded 
and communicating systems. Our proposal is based on the connectivity 
fault model proposed by [8], where faults may occur in the interface 
between the software and its environment rather than in the software 
implementation. 

We show that the test generation task can be carried out by solving a 
reachability problem in a system consisting essentially of a specihcation 
of the communicating system and its fault model. Our technique can 
be applied using most off-the-shelf model-checking tools to synthesize 
minimal test sequences, and we demonstrate it using the UppAal real- 
time model-checker. 

We present two algorithms for generating minimal tests: one for single 
faults and one for multiple faults. Moreover, we demonstrate how to 
exploit the unique time- and cost-planning- facilities of UppAal to derive 
cheapest possible test suites for restricted types of timed systems. 



1 Introduction 

Testing modern embedded and communicating systems is a very challenging 
and difficult task. In part, this is due to their complex communication patterns 
and by their reduced controllability and observability caused by the embedding 
and close integration with hardware. Although testing is the primary validation 
technique used by industry today, it remains quite ad hoc and error prone. 
Therefore there is a high demand for systematic and theoretically well founded 
techniques that work in practice and that can be supported by automated test 
tools. 

A promising approach to improve the effectiveness of testing is to base test 
generation on an abstract formal model of the system under test (SUT) and use 
a test generation tool to (automatically or user guided) generate and execute test 
cases. A main problem is to automatically generate and select a reasonably small 
number of effective test cases that can be executed within the time allocated to 
testing. 

This paper presents a technique for (formal) model-based (extended-finite 
state machines) black-box behavioral testing of embedded systems where a par- 
ticular fault model, connectivity faults, is used to select test cases. Moreover, we 



D. de Frutos-Escrig and M. Nunez (Eds.): FORTE 2004, LNCS 3235, pp. 167-184, 2004. 
(c) IFIP International Federation for Information Processing 2004 



168 



Jens Chr. Godskesen et al. 




Fig. 1. An idealized view on embedded systems (a) and faulty embedded systems (b) 



demonstrate how such test cases can be generated using the diagnostic trace fa- 
cility of a standard, unmodified, model checking tool using standard reachability 
analysis. 



1.1 Connectivity Testing 

An embedded system may as presented in [8] idealistically be regarded as con- 
sisting of embedded software encapsulated by hardware, like depicted in Fig- 
ure 1(a), where all communications to and from the software pass through the 
hardware. This is visualized by letting the inputs from the system environment 
to the software (a, b, c, d, e) pass through the hardware towards the software via 
connections (the unlabeled arrows). Likewise the outputs (0, 1,2,3) generated 
by the software have to pass via connections through the hardware in order to 
emerge at the system environment. 

A connection is by assumption related to exactly one input or output. This 
assumption implicitly implies that there is a one to one correspondence between 
external inputs to the system and the inputs to the embedded software, likewise 
there is a one to one correspondence between the outputs from the software and 
the outputs from the system. 

Ideally it should be ascertained that the specification of the software com- 
ponent is correct. For instance, it may have been verified by some FSM verifica- 
tion technique. Then exploiting the ability to automatically generate executable 
code from specifications and assuming a careful construction of such compilers 
it would be reasonable to expect the generated code to be correct with respect 
to the specification, that is the two perform the same FSM behaviour. 

In the composition of the two system components it then follows that the 
hardware (and probably drivers managing the interaction between the hardware 
and the software or malfunctioning sensors and actuators) may be the only error 
prone part. Therefore, in order to manage the multitude of potential errors we 
shall make an abstraction and regard the hardware (and the drivers, sensors, 
and actuators) as a black box interfacing the embedded software through the 
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connections. As a consequence system errors may now only be referred to in 
terms of the connections. 

In the system in Figure 1(a) a fault could for instance be that one of the input 
connections is missing as shown in Figure 1(6), where the 6-input is disconnected. 
In the physical world, say for a mobile phone for instance, this may correspond 
to the situation where some button of the phone is not connected such that the 
software will never receive the input, and therefore the pressing of the button 
will cause no effect. 

To ensure that the faults are testable they are assumed to be permanent. 
Testing in order to detect the kind of faults addressed in this paper is a matter 
of providing sequences of inputs that will reveal the missing connections. If say 
the 6-input connection in Figure 1(a) is missing this may be revealed by an 
input sequence containing 6 and where eventually an expected output event is 
not produced or (in case the system is not input enabled) an expected input is 
not allowed. 

We require that test generation is sound and complete, but from a practical 
perspective the generated suite should also be cost effective, e.g., in terms of test 
execution time. Thus, the suite should be minimized in the number of tests and 
length. 

1.2 Contributions 

We provide algorithms for generating tests for embedded systems with respect 
to fault models for input connectivity errors where for the system under test, it 
is assumed that the embedded software behaves as an FSM. By exploiting a real- 
time model-checker like UppAal [13] we are able to generate timed test sequences. 
However, to ease presentation we define our algorithms in the untimed setting of 
I/O deterministic EFSM (previous work [8] defined connectivity errors in term of 
Mealy machines) . We prove that a minimal length sound and complete test (with 
respect to single connectivity faults) can be found via a reachability question of 
a composition of the system model, its fault model, and a simple environment 
model. We extend the basic algorithm to generate a minimal length test for 
multiple connectivity faults, and we prove its soundness and completeness. 

Previous work [8] provided dedicated, heuristic polynomial time reduction 
algorithms; ours always produce the minimal (at the expense of increased com- 
plexity). Our algorithms can be implemented in most model-checking tools, but 
are additionally valid for a particular class of timed automatons using a real-time 
model-checker like UppAal. It symbolically solves clock constraints to perform 
reachability analysis on a network of timed automata, and produces a timed di- 
agnostic trace (an alternating sequence of discrete transitions and time delays) 
to explain how the property is (is not) satisfied. We demonstrate the applicabil- 
ity of the algorithms on a medium size example (a cruise controller) ~ both in 
an untimed and a timed version, and indicate how the unique time- and cost- 
optimizing features of UppAal can be used to generate optimal tests. 

The paper is organized as follows: Section 2 formally presents I/O EFSM’s 
and tests. Section 3 presents the modelling of connectivity faults and illustrates 
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how to test for such faults. Section 4 and Section 5 respectively present the 
algorithm for single and multiple faults. Section 6 presents the case study, and 
Section 7 elaborate on generation of time- and cost- optimal tests using UppAal’s 
unique diagnostic trace features. Section 8 concludes and outlines future work. 

1.3 Related Work 

The use of diagnostic traces produced by model-checkers as test sequences has 
been proposed by many others [2, 3, 5, 6, 7, 10, 11, 15, 9]. A simple approach is 
based on manually stated test purposes, (i.e specific observation objectives to be 
made on the system under test) such as observing a given output, or bringing the 
SUT to a given state or mode, see e.g.,[6]. The test purpose is then formalized 
and translated to a logical (reachability) property to be analyzed by a model- 
checker. The resulting diagnostic trace is interpreted as a test case for that test 
purpose. 

Another common approach is based on producing test suites that satisfy some 
coverage criteria of the specification, e.g. state- or transition- coverage, def-use 
pair coverage, MC/DC coverage etc. The simplest way of realizing e.g., transition 
coverage is to formulate a property for each transition separately and use the 
model checker to produce a test case for each transition. More advanced tech- 
niques will naturally try to reduce the size of the test suite by removing re- 
dundant prefix-traces [15] or composing test cases by generating (minimal [9]) 
transition tours, [11, 9]. 

In [2] mutation testing is considered although in another setting than ours 
(they consider software testing). Mutations are used for generating tests to im- 
plementations of FSM’s using model checking. Given is an FSM, M, and a con- 
straining temporal logic formula, (j)- A mutation may be either a change of a tran- 
sition in M, or a change of cj). For each mutation a test is generated as a counter 
example as to why M ^ (f> {if M ^ (p). Duplicates and test being prefixes of 
other tests are removed, hence they do not as in our case generate a smallest 
possible test suite. 

2 I/O EFSM 

In this section we define input/output extended finite state automata (I/O 
EFSM) and their semantics. 

Definition 1. An I/O EFSM is a tuple 

M=(S,I,0,X,so,^) 

where S is a finite set of states, sq G S is the initial state, I and O are finite 
disjoint sets of input and output labels respectively, X is a finite set of integer 
variables, and — >C S x Gx x (lUO) xAx xS is a transition relation, Gx is a set 
of guards, over the variables in X, and Ax is a set of finite sequences (possibly 
the empty sequence e) of assignments to variables in X . Each guard is a boolean 



Connectivity Testing Through Model- Checking 171 



expression over integer constants and variables in X, and each assignment is on 
the form x := e where x G X and e G Ex is a arithmetical expression over the 
variables in X and integer constants. 



we write s s'. We write s s' (s 



Whenever {s, g, a, a, .s') G- 
s') instead of s s' (s g'), 'VVe write s s' instead of s s'. 

Often we write al (a?) whenever a is an output (input) symbol. Note that, for 
reasons of clarity and ease of presentation, we have omitted internal r actions; 
our algorithms can easily be adapted to handle these as well. 



2.1 Semantics 



The semantics of an I/O EFSM M is a labelled transition system defined wrt. a 
valuation function assigning values to the variables of M and used to evaluate 
the guards on transitions. 

Definition 2. A valuation v for a set of integer variables X is a function v : 
X N. We let Vx denote the set of all valuations for X. Ox G Vx is the 
valuation where Ox(a;) = 0 for all x G X. For n G N, v[x n] evaluates all 
variables y to v{y) except x that is evaluated to n. 

Given a valuation v G Vx, the value of a guard g G Gx with respect to v, 
denoted by v{g), is the obvious evaluation of the boolean expression g relative 
to V. Moreover, for a sequence of assignments a G Ax, v(a) G Vx is defined 
inductively by v{e) = v and v(x := e,a) = v[x n](a) where n is the value 
obtained by evaluating expression e using the valuation v. 

The semantics of an I/O EFSM is defined as a labelled transition system. 

Definitions. Let M = {S,I,0 ,X,sq, — >m)- The labelled transition system 
induced by M is 

Tm = {S X Vx, I Gi O, (sq. Ox), — >) 

where (sq,0x) G S x Vx is the initial state. The labelled transition relation 
— >C (S' X Vx) X (/ U O) X (S X Vx) is the least relation satisfying: 



q.Oi.a / 

S s 



(s,v) (s',?^(a)) 



v{g) is true 



Whenever (s,v) (s',v') we write (s,v) (s',v') if a G I, otherwise if 

a G O we write (s,v) (s',v'). 

We say that a transition system is I/O deterministic if for any state there are 
at most one output transition and at most one input transition for any input. M 
is I/O deterministic if its induced transition system Tm is I/O deterministic. 

Two automatons M and M' are equivalent, M ~ M' , if the initial states 
in Tm and Tm' are trace equivalent. 
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We only consider the parallel composition of I/O EFSM’s at the semantic 
level. By convenience, and without loss of generality, we assume all machines 
have the same variables. It follows from the definition that output actions are 
broadcasted. 



Definition 4. Let Ti = {Si x Vx,Li, (sq. Ox), — >i), i = I, . . . ,k be I/O EFSM 
induced labelled transition systems. The parallel composition IL^^/Ti is defined 
by 

nt/T, = ((5i X ... X X Vx, {{si . . . , 4). Ox), -^) 

where L = and — > is the least relation satisfying 



{si,v) 



{si,Vj) Vj / i- {sj,Vj) {s^Vj) 

{{su...,Sk),v)^{{s[,...,s',),v') 



where {s,v) (s',w') if{s,v) (s',z;') and {s,v) (s,r>) if{s,v) /^n 

and v' is a valuation accumulating all the updates v[, . . . 



2.2 Tests 

In our setting a test is an I/O EFSM except that each state is annotated by 
either the verdict pass or fail. 

Definition 5. Let I and O be finite disjoint sets of input and output symbols 
respectively. Let a\ . . . an G (/ U O)'^ . Define the test 

O) = ({so, . . . , s„}, I, O, so, ^) 



such that 



is the least relation where 



ai Oi'2 

So > Si — >■ 



and where Sn is annotated by pass and all so,...,s„_i are annotated by fail. 
Define Mlf'l^^{I,0) as MP///^^{I ^O) except that the state s„_i is annotated 
by pass and the remaining states by fail . 

If in every complete run of Tm || Txi^i^j^o) component q) terminates 

in the state pass {fail) we say that M passes (fails) the test Mf{I, O); otherwise 
I/O deterministic Tm || Tm^{i,o) has precisely one complete run. 

^ We leave out the formal definition of v' . Our algorithms make use of shared vari- 
ables between automatons but carefully ensure that simultaneous updates cause no 
problems. 
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Fig. 2. A simple model M and its mutants M\a], M[c]. The initial location is 

doubly encircled 



3 Modelling and Testing Connectivity Faults 

As mentioned previously, a connection is assumed to be related to exactly one 
input^. That is, when the connection related to a given input (say a) is faulty, 
the software will not receive any a-input, i.e. the state of the software will remain 
unchanged, whenever the environment makes an input to the system via a. We 
can therefore model a connectivity fault as a so-called mutation M[a\ of a correct 
model M by changing all a-transitions so that the state is not changed. This is 
made precise in the following definition: 

Definition 6. Let M = (S', /, O, X, sq, — >) and a G I. Define 

M[a] = (S,/,0,X,so,^i) 

where — >i is — > except that all transitions s s' are replaced by s s. 

Figure 2 shows a simple model with 3 inputs (a,b,c) and the mutants 
PI[a],M[b],M[c\. An a-connectivity fault may be found by applying a test that 
distinguish M from M[a]. For the mutants M[a], M[b], and M[c] in Figure 2, we 
may construct the tests O), O), and O) respectively 

where I = {«;} and O = {a, 6, c}. Clearly, the tests are minimal (in terms of the 
number of synchronizations between the tester and the system) and O) 

and O) are sufficient to distinguish M from all three mutations. There 

exists no single test distinguishing M from all the mutations. 

4 The Test Generation Algorithm 

In this section we present an algorithm for generating a test that distinguish an 
I/O EFSM from a single mutation (if they are distinguishable). In the algorithm 

^ We restrict ourselves to input faults. However, the extension to output faults is 
straightforward . 



174 



Jens Chr. Godskesen et al. 



we use the following two operators: M? is M where outputs become inputs and 
M(x := e) is M where on any transition x is updated by e. Formally we have 

Definition 7. Let M = {S, I, O, X, sq, — >) then Ml = (S,IU 0, 0, X, sq, — >). 

Definitions. Let M = {S,I,0,X,so, — >)• Then for any x and e G Exu{x} 

M{x := e) = {S,I,0,X U {x},so, — >i) 

where — is — > except that for every a € I U O, any s s' is replaced by 

g,a,a' , , , . 

s — > 1 s where a is a, x := e. 

We let M{xi, . . . ,Xk ■= e\,...,ek) be M{x\ := ei)...{xk '■= Ck) when- 
ever a G Exu{xi}, i=l,...,n. 

4.1 The Algorithm 

The problem we want the algorithm to solve is the following: 

Given an I/O deterministic EFSM M and one of its input symbols a, if 
M ^ M[a] then find a test M' with fewest possible states such that M 
and M[a] respectively passes and fails M' . 

Intuitively, the idea behind the algorithm is to put M and its mutation to- 
gether in parallel with a third machine, the environment E. Only E is allowed to 
submit actions, the other machines are modified to contain solely input actions. 
The role of E is to broadcast actions such that whenever the two other machines 
do not agree on receiving an action (recall they are I/O deterministic) a fault 
has been detected. The algorithm searches for a shortest possible trace of actions 
broadcast by E leading to a fault. 

Pseudo Code 

1. Let X, y and z be disjoint variables none of which belong to X. 

2. Let E = ({s}, 0, 1 U O, A U {x, y, z}, s, {(s, /3, s) | /3 G / U O}). 

3. Let Cl and C 2 be distinct constants and let Mi = Ml{x,y,z := (x + 
1)%2, y, Cl) and M 2 = M[a]?(a;, y, z := x, {y + 1)%2, C 2 ). 

4. Construct Te || 7mi || Tm 2 with initial state st- 

5. Let t, if it exists, be a minimal trace such that st — ^ {st,vt) with vt 
satisfying x ^ y.lit doesn’t exists return false. 

6. If Vt{z) = Cl return /), otherwise return m/“*(0,I). 

The only technicality of the algorithm is the use of the variables x, y, and z. 
The role of x and y is to count (modulo 2) whenever Ml and M[a]? respectively 
have synchronized with E. Hence, whenever x ^ y & fault have been detected. 
The role of z is to register which of Ml and M[a]l engaged in a synchronization 
with E, this is important as to wheter the returned test should be a test with 
verdict pass or fail. 

The correctness of the construction of the test automaton follows from the 
theorem below. 
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Theorem 1. If the algorithm on input M and a returns false then M ~ 
otherwise it returns a test M' with fewest possible states such that M passes M' 
and M[o\ fails M' . 

4.2 Example 

If we apply the algorithm on input M (Figure 3) and action b then the three ma- 
chines put in parallel, Mi, M 2 , and E, are as devised in Figure 3. For illustrative 
clarity x++ is taken to mean x incremented modohis 2. 

The test M^l^{{w},{a,b,c}) is a minimal length test that may be con- 
structed by the algorithm. Clearly, awbc is a shortest possible sequence leading 
to a state in Te || Tmi || Tm^ where x ^ y, and since only M 2 can engage in the 
last event c the value of z is C 2 - 

5 The Generalized Algorithm 

Next, we generalize the algorithm above such that a whole suite of test automa- 
tons are generated for a set of mutations (if all mutations are distinguishable 
from M). 

5.1 The Algorithm 

The problem the algorithm solves is 

Given M = {S,I,0,X,so,—^), an I/O deterministic automaton, and 
a set of input symbols A C /, if M / M[a] for all a € A, find a minimal 
test suite Ai such that 1) M passes all automatons in A4, and 2) for all 
a S A, M[a] fails M', for some M' G Ai. 
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Notice, that a minimal test suite AJ satisfies that for all M' G AJ there exists 
a & A such that M[a] fails M' and M[a] passes all other test automatons in At, 

i.e. all tests returned by the algorithm are indeed needed and cannot be removed 
from the suite if all connectivity faults are to be revealed. 

The main idea is to extend the previous algorithm by running all mutants con- 
currently, but tightly synchronized, with the unmutated automaton M . When- 
ever the unmutated machine M cannot match a transition by one of its mutations 
a connectivity error has been detected, and M needs to be reset (and only then) 
to extend the sequence to kill more mutants. 



Pseudo Code 

1. Let {x,Xa,ya,z \ a G A} he fresh variables disjoint from X. Extend M to 
contain the variables Y = X\J {x, Xq, j/q, z | a G A}. 

2. Let M' = Ml{x := {x + 1)%2) and let for all a G A, = M[a]l{xa ■= 
(xc. -k 1)%2) 

3. Let go and reset be two new fresh actions not in /UO. Add {go, reset} to the 
set of output labels for M' . Let M" be M' with any transition s s' where 
a G / U O, replaced by s s" s' sq where for each replacement 
s" is a new fresh state. 

4. For each a G A, add {reset} to the set of input labels for Ma and add a reset 
transition, s sq, for any state s in Ma to its initial state sq- 

5. Let E = ({so) si}) {go, reset}, I U 0,Y, sq, — >) where 

— > ={(so, (a, 2 := 0),si) |a G /U O} U {si — > so,si — > so} 

6. Construct M'^ = ({sq, si}, 0 , 0 , E, so, — *■) for all a G A where sq si 
with a = {ya '■= 1) and g = (x yf Xq). 

7. Construct Te || Tm" || EaeATMa II niaeATM^ with initial state st- 

8. Let P be z yk 0 A Vo G A. j/q yf 0. 

9. Let t = t'(3, if it exists, be a minimal trace such that st — ^ (st,xt) with vt 
satisfying P. If t doesn’t exists return false. 

10. Let ti, . . . ,tk be such that u = tireset t 2 ■ ■ ■ reset tk where u is t' with all go 
and r’s removed. 

11. Return Xi = {O, {O, /)} where v is fail if /J = 

reset, otherwise if P = go then v is pass. 

To control when M has to be reset every a transition by M is now fol- 
lowed by a new output action called go which intuitively acknowledge to the 
environment E that M could match a. After having ouput an action, E waits 
for this acknowledgement before it sends a new action. If the acknowledge does 
not arrive E knows that M could not perform the action, implying that a test 
has been found for at least one of the mutations. In that case the only possible 
synchronization is a reset between M and the environment automaton. 

In order to detect when a connectivity error has been identified we introduce 
an observation automaton M'^ for each mutation a. It consists of two states and 
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Fig. 4. The annotated automata {Ma, Me, M'^, M^, omitted). The notation v[i\ is 
UppAal notation for indexing array v at position i. bid is the position for action b 



one transition that fires when M and M[a] does not agree on some input or 
output transition, i.e. when x ^ Xa. All mutations have been revealed when all 
observation automata has fired, i.e, when all t/a = 1- 

Based upon the trace t = t' f3 found (if a trace is found) a set of test au- 
tomatons are constructed. First all go’s and t’s are removed from t'. Then t' 
is split in the parts t\, . . . ,tk separated by reset labels. For all ti, but tk, fail 
test automations, I) are created, since M clearly cannot perform those 

traces — that was the sole reason why M was reset. To be able to tell whether the 
final part, tk, should give rise to a fail or pass test automaton we force the trace 
to always end with either reset or go. This is done by introducing a variable z in 
the environment automaton that is set to 0 on transitions with labels in / U O 
and to 1 when a go or reset is performed. Then searching for t we require z is 
not zero. Clearly, if the last event in t, i.e. j3, is a go then 1) is created, 

otherwise if it is reset then is created. 

Notice, that a test automaton Mf {0,I) may detect several mutations. 

Theorem 2. If the algorithm on input M and A returns false then M ~ M[a] 
for some a € A, otherwise it returns some A4 satisfying the properties in Sec- 
tion 5.1. 



5.2 Example 

Given the I/O EFSM M in Figure 2 the algorithm produces the se- 
quence awbb. reset. aweb. reset, resulting in the two tests M^lf^{{w},{a,b,c}) 
and {a, b, c}). Both tests for connectivity of a. The used annotated 

models are depicted in Figure 4. 
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C l<res umeDelay 
on? 



ri -fU W 

■ x]2<=controlDelay Cl<=resumeDelay 

(a) (b) 

Fig. 5. User Interface Automaton (a) Timed user interface (b) 



6 Cruise Controller Example 

In this section we exemplify and benchmark our technique on a medium sized 
cruise controller example. The cruise controller is commonly studied and found 
in many variations in the literature, and thus serves as an illustrative example, 
see e.g., [14, 2], 

6.1 The Cruise Controller 

The model consists of two automatons. The user interface controls the different 
modes of operation according to the various user inputs, whereas the speed con- 
trol keeps the actual speed close to a given desired speed by affecting the throttle 
of the engine. 

The user interface (Figure 5(a)) basically has four modes, i.e. inactive when 
the engine is turned off, active when the engine is turned on, cruising when 
the speed control is enabled, and standby when the speed control is temporarily 
suspended. When the engine is turned on, the desired speed is cleared, and when 
cruise mode is entered, the actual speed is recorded and set as the desired speed. 
The cruise mode may be reentered from standby mode. 

The speed control (Figure 6) switches between its two operational modes 
disabled and enabled according to enable and disable control signals from the 
user interface. In disabled mode, it sets the desired speed to zero or to the 
sampled actual speed when commanded by the user interface. In enabled mode, 
it samples the actual speed and based on the difference between actual and 
desired speed (represented by variables cSpeed, dSpeed), it stops acceleration 
of the engine (output incO), or commands the engine to do medium (output 
incl) or high (output inc2) acceleration. Further, in enabled mode, the user can 
manually increase or decrease the desired speed. 
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recordSpeed? 

dSpeed:=cSpeed 



deer? 

dSpeed:=dSpeed>0? 

dSpeed-l:dSpeed cSpeed-dSpeed>=maxdiff && 



acol 

inc2! 




dSpeed:dSpeed+l 



clearSpeed? 

dSpeed:=0 



Fig. 6. Speed Control Automaton 



The actions of the user interface are = {engineOn, engineOff, on, suspend}, 

Ou = {clearSpeed, recordSpeed, enableControl, disableControl}. The actions of 
the speed ontroller are Is = OuU{incr, deer, getspeed, }, Os = {incO, incl , inc2}. 
For the system composed of the user interface and speed controller synchronizing 
internally^ on actions Cl /«, the actions are Ic = /^ U /^ \ 0„, Oc = Os- 

6.2 Generated Test Sequences 

Unless the length of the test suite is important, the normal and computationally 
most efficient method is to generate a separate test sequence for each mutant. 
Our experimental results show that a sequence could be successfully generated 
for each mutant; also the sequences are quite short. The test suites generated 
for the cruise interface, the speed controller and the composed system contain 
respectively 5 (16), 7 (31), 8 (34) test cases (total steps). All were generated on 
a standard PC in less than one second. Table 1 lists some examples. 

These results indicate that our technique may be feasible for much larger 
systems, both in terms of test suite size and model size (number of inputs and 
state space) . Since the algorithm generates the minimal sequences, some of them 
are quite surprising and would not likely be found by hand, e.g., the test for engi- 
neOn. Observe especially that it is not obvious how the desired and current speed 
should be set to distinguish the mutants of the speed controller. For instance, it 



would be incorrect to use the intuitive test MP2lleControL^ncr.getspeed.^ncoiOs, L) 



to check for connectivity of incr because incO would also be output if incr was 
disconnected (given that maxDiff = 2, dSpeed and eSpeed initially equals 0, ace 
becomes 0 in both cases). Hence at least two increments are needed. 

Also note that — because our algorithms does not require the specification 
or implementation to be input enabled — not all sequences end with an output, 

® Recall that our technique can be adapted to handle these. The semantics of the input 
fault mutations in a composed system is as if they were made to their (synchronous) 
product I/O EFSM, hiding internal communication channels. 
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Table 1. Selection of Generated Tests (if v =P then {O , I)\ if v =F 

then M{'^'\0,I)) 



Mutant 


V 


Generated Event Sequence t 


User Interface 


engineOff 


p 


engineOn. clearSpeed. engineOff. engineOn 


suspend 


p 


engineOn. clearSpeed. on. record Speed. enableControl. suspend. disableControl 


resume 


F 


engineOn. clearSpeed. on. records peed. enableControl. suspend. - 
disableControl. resume. engineOff 


Speed Controller 


incr 


P 


enableControl. incr. incr. getspeed.incl 


deer 


P 


enableControl. incr. incr. deer. getspeed.incO 


clearSpeed 


P 


enableControl. incr. incr. clearSpeed. getspeed.incO 


Cruise Controller System 


engineOn 


F 


engineOn. engineOn 


resume 


F 


engineOn. on. suspend, resume, resume 


incr 


P 


engineOn. on. incr. incr. get Speed, incl 



meaning that if the last input can be performed by the tester, the test will 
pass (or fail, depending on the verdict). If this is felt to be unnatural for some 
applications, it is very easy to force our algorithms to produce tests that ends 
with an output. The generated test for engineOjf is then 



j^pass 

engineOn. clear Speed. engineO ff . engineOn . clear speed 



{OuJu). 



6.3 Multi- fault Test Sequences 

In some cases it is important to produce a smallest test suite with as few and 
short tests as possible. A simple reduction technique like prefix elimination does 
not work well for connectivity testing (see sequences presented in Section 6.2). 
Our generalized algorithm from Section 5 is therefore more involved and guar- 
antees that the minimal length test suite is computed, although at the expense 
of computational complexity (the problem is NP-hard [8]). It involves analyzing 
a system consisting of all mutants running concurrently in a synchronized step- 
lock fashion. Thus, state space explosion theoretically limits how many mutants 
can be composed, and it should be examined where this limit occur in prac- 
tice. The following experiments are run on a 8x900 MHZ Sun Sparc Fire v880R 
workstation with 32 GB memory running Sun Solaris 9 (SunOS 5.9). However, 
UppAal only exploits one CPU and addresses at most 4 GB of memory. The 
results are tabulated in Table 2. 

For the user interface, it turns out that it is possible to com- 
pute (using only a few seconds and megabytes of memory) a sin- 
gle test of 11 steps that detects all input faults Mf“^(0„,0u) where 
t = engineOn. clearSpeed. on. records peed. enableControl. suspend. disableControl. - 
resume. enableControl.engineOff.disableControl, giving a reduction of 31% (11 
versus 16 steps). 

The speed controller and the composed system have much larger state spaces 
and are more challenging. Still, all mutants but two could be composed in 
both cases. The multiple-fault test suite (up to and including the incr mu- 
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Table 2. Performance of multi-fault algorithm 



Speed Control 


Cruise System 


Mutant(s) 


CPU-time(s) 


Memory (KB) 


Mutant(s) 


CPU-time(s) 


Memory (KB) 


enableControl 
-\- disableControl 
clear Speed 
recordSpeed 
-\-incr 
-\-decr 
-\-getspeed 


0.21 

0.37 

10.98 

152.77 

1917.02 


3704 

5672 

29008 

281072 

2128824 


engineOn 
-\-engineOff 
-{-resume 
+ on 

-{-suspend 

-{-incr 

-{-deer 

-{-getspeed 


0.16 

0.29 

27.51 

39.01 

50.60 

874.00 


5232 

5584 

97608 

100208 

131192 

1516800 



tant) for the speed control consists of two tests: Is) and Is) 

where t\= enableControl. incr. incr.getspeed. incl. recordSpeed. incr.getspeed. incO. - 
clearspeed.getspeed.incl, t 2 = enableControl. disahleControl.incr, giving a reduc- 
tion of 25% compared to detecting the same faults using seperate sequences. 
In addition many system resets are avoided. The cruise system (up to incr) 
requires only one test: M(°'''\Oc, Ic) where t= engineOn.engineOff.engineOn.- 
on.suspend.resume. incr. incr. getspeed.incO, giving a reduction of 40%. The order 
of addition of mutants was arbitrary. Even if the test suite is generated by more 
rounds composing only some of the mutants each time, the reduction in test 
suite size is significant. 



7 Timed Test Generation 

We next demonstrate how connectivity tests for a class of timed systems can be 
generated. The tester now needs to be time aware to reveal them. This result re- 
quires no change to the basic algorithm if a real-time model-checker like UppAal 
is used. 

Informally, a timed automaton [1] is an I/O EFSM equipped with a set of 
non-negative real- valued variables called clocks that may be used in guards, and 
may be set to zero on transition assignments. In addition, location invariants 
forces the automaton to take a transition before it becomes false. The semantics 
of a timed automaton is defined in terms of an infinite timed transition system 
consisting of both discrete transitions and time delay transitions. To ensure 
testability we impose similar semantic restrictions as in [16]: Our model, called 
DOUTA, are deterministic, output urgent (an output or r occurs as soon as it 
is enbled) timed automata. DOUTA is formally defined in [9]. 

Consider the following real-time requirements for the user-interface automa- 
ton in Figure 5(a). 1) For safety reasons, the engine must be on for at least 
onDelay before cruise control may be switched on. Earlier requests must be ig- 
nored. 2) When cruise mode is suspended, at least resumeDelay must elapse 
before reengagement to avoid too rapid enabling and disabling of the speed con- 
troller. 3) It takes controlDelay to enable or disable the speed controller (involves 
external communication), whereas the speed can be set or cleared with a zero 
delay (assumed internal communication) . These requirements are satisfied by the 
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DOUTA in Figure 5(6). Boldfaced clock constraints below locations are location 
invariants. 

Given this specification (onDeJaj=5000, controlDelay=3000, controlDe- 
Jay=200) UppAal produces the following timed test lu) to reveal 

disconnection of the resume action, where t= 0.engineOn.0.clearSpeed.5000.- 
on.O.recordSpeed. 200. enableControl.O. suspend. 200. disableControl. 2800. resume.- 
O.engineOff . Note that the delays are not a trivial insertion of the delay 
constants occurring in the model (e.g the 2800 ms between disableControl and 
resume). It is usually infeasible to compute these by hand because it involves 
solving a large set of inequations on clock variables. The zero delays in the 
above sequence can be avoided by replacing the universal environment E by 
a more accurate (and slower) environment model timed automaton E' which 
restricts the choices of the tester. 

UppAal also has efhcient facilities for generation of time- and cost- opti- 
mal diagnostic traces [4, 12]. In fact, the above test is not only of minimal 
length, but also the fastest (minimal accumulated time delay). To avoid expen- 
sive operations, e.g., resets, UppAal can be used to generate suites with the 
fewest such operations. As a simple example, the generated multi-fault test pre- 
sented in Section 6.3 for the speed controller required two tests, and thus one 
reset. Searching for a test with fewer resets UppAal found one (only two com- 
munication events longer that the minimal length test suite): {Ou, lu) 

where t= enableControl.incr.clearSpeed.incr.getspeed.incO.incr.getspeed.incl.- 
disableControl.enableControl.clearSpeed.recordSpeed.incr.incr.getspeed.incl. It is 
also possible to take the actual time/cost for a reset into account. 

8 Conclusions and Future Work 

This paper describes two sound and complete algorithms that generate minimal 
test cases and test suites respectively for input connectivity faults. The algo- 
rithms are based on reachability analysis and may thus be implemented in most 
model-checkers. Based on experiments with a concrete model-checker, UppAal, 
and a medium sized example, we conclude that our techniques are feasible, and 
for the simple algorithm appear to scale to larger systems. For the generalized 
algorithm the number of simultaneous mutants that can be handled is limited 
due to state space explosion (recall that the problem is NP hard). Finally, we 
show how timed connectivity and examples of cost optimized test suites can be 
generated by the same algorithms. 

We only looked at input connectivity faults, however it is trivial to generate 
test sequences for output connectivity faults, since this amounts to finding a se- 
quence that visits a transition where the output is produced, hence making it 
observable. 

As future work we plan to examine other more involved fault models, 
e.g. models where connections may be whole protocols. Since our algorithms are 
based on finding a trace that can be performed by the original automaton and 
not its mutant, or vice versa, our algorithms appear to be so general that many 
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other fault models can be supported. In particular we plan to investigate how 
to test wrongly interconnected communicating (distributed) components that 
have been tested or verified in isolation. Also, we plan to investigate a timed 
connectivity fault model where disconnects are not permanent and we intend 
to do practical application and further experiments with time-and cost-optimal 
test suite generation. 
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Abstract. In this paper we use equation solving for translating internal tests 
derived for a component embedded within a composite system into external 
tests defined over the external alphabets of the system. The composite system is 
represented as two communicating finite state machines (FSMs), an embedded 
component FSM, and a context FSM that models the remaining part of the 
system and which is assumed to be correctly implemented. Application 
example is given to demonstrate the steps of the method. The method can be 
adapted for test derivation for a system of two or more communicating FSMs. 



1 Introduction 

Several methods have been developed for testing a component embedded within a 
composite system [12]. Usually the composite system is represented as two 
communicating machines, an embedded component machine, and a context machine 
that models the remaining part of the system and that is assumed to be correctly 
implemented. 

A number of test derivation methods have been proposed for testing in context 
when the system components are modeled as Finite State Machines (FSMs). Some of 
these methods [4, 15] return test suites that satisfy appropriate test purposes. 
Flowever, these test suites are not complete, i.e. they do not detect all possible faulty 
implementations of the embedded component. Other methods [for example, 14] return 
complete but redundant test suites since they consider fault domains that include 
infeasible implementations that do not correspond to any possible implementation of 
the embedded FSM. Accordingly, in order to alleviate the problem of infeasible 
machines, tests can be derived directly from the embedded component machine as 
proposed in [18, 20]. In this case, a test suite is derived based on the largest set of 
permissible behaviors of the embedded component FSM that is a largest solution to an 
appropriate FSM equation. Usually, a largest solution is a nondeterministic FSM, and 
a test suite is derived w.r.t. the reduction relation. Flence the methods presented in 
[11, 19, 22] can be used for deriving corresponding test suites. Flowever, tests 
generated by all of the above methods are given in the form of input/output sequences 
defined over the input/output alphabets of the embedded machine, i.e. over internal 
alphabets. These tests are then translated, using adhoc methods, into external tests 
defined over the external observable input alphabets of the system. The problem of 
translating internal tests into external ones is called the fault propagation problem and 
is known to have exponential complexity 
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In this paper we present an equation solving based approach for solving the fault 
propagation problem. The equation solving problem is to describe a behavior of a 
component of a system knowing the specifications of the other components and the 
specification of the whole system. In 1980, a first paper [2] (see also [16]) gives a 
solution to the problem for the case where the system behavior is described in terms 
of labeled transition systems (LTS). This work was later extended to the cases where 
the behavior of the components is described in CCS or CSP [17], by FSM [21, 26] or 
input/output automata [6, 13, 23]. Moreover, the applications of the equation solving 
problem were first considered in the context of the design of communication 
protocols [16]. Later it was recognized that equation solving this method could also 
be useful for the design of protocol converters in communication gateways [10, 13, 
24], and for the selection of test cases for testing a module in a context [20]. Another 
application area of equation solving is the design of controllers for discrete event 
systems [1, 27]. 

We solve the fault propagation problem using equation solving as follows: Given 
the specifications of the context and embedded components, first, we derive the 
largest set of permissible behaviors of the embedded component FSM as the largest 
solution to an appropriate FSM equation. The FSM equation is solved using the 
automata based equation solving method presented in [3]. Then, we derive, using the 
method proposed in [19], from the largest FSM solution, internal tests for the 
embedded component FSM. These tests are derived w.r.t. the reduction relation since 
the largest solution is generally non-deterministic. The internal tests are then 
represented by an appropriate automaton. This automaton is used with the automaton 
that represents the context to solve an appropriate automata equation. External tests 
are then derived from the solution to the latter equation. 

This paper is organized as follows. Section 2 includes necessary FSM and 
automata definitions and an overview of testing in context. Section 3 includes our 
method for translating internal tests by equation solving with a related application 
example. Section 4 concludes the paper. 

2 Preliminaries 

2.1 Finite State Machine 

A finite state machine, often simply called a machine, is a quintuple A^{S,I, 0,Ta,Sq), 
where 5 is a finite nonempty set of states with the initial state ^o, I and O are input and 
output alphabets, and Tj^SxIxOxS is a transition relation. We say that there is a 
transition from a state s e 5 to a state s'e S labeled with an I/O pair Ho, if and only if 
the 4-tuple {s,i,o,s') is in the transition relation T^. FSM A is observable if for each 
triple {i,s,o)e IxSxO there exists at most one state ne S such that (i,s,n,o)e T^. An FSM 
A is called deterministic, if for each state se S and each input ie I there exist at most 
one pair of output o and state ^ ', such that (^, i,o, s ')e T^.lfA is not deterministic, then 
it is called non-deterministic. FSM B = {Sb,I,Ob,Tb,Sq), where Sb £ and Ob £ Oa, 
is a submachine of FSM^ = (5)|,/, Oa,Ta,So), if V(^', ;) g SbXI (Tb £ Ta). 

As usual, the transition relation Ta of the FSM A can be extended to sequences over 
the alphabet I. The extended relation is also denoted by Ta and is a subset of 
SxI*xO*xS. By definition, for each state seS of the FSM A the tuple ') is in 
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the relation Ta. Given a tuple (s,a,/3,s')eTA, aef, PeO*, and an input i&I and an 
output oe O, the tuple (^, ai, jh, s ") e Ta, if and only if i, o, s ") e Ta. Given state 
s, an I/O sequence i\Oi...iifik, I , 0 \... 0 k^ I , such that {s,i\...ik, 0 \...Ok, ^') e Ta 

is called a trace of A at state s. The set of all traces at state ^ is denoted Zr^(s'). We 
denote Tva the set of traces at the initial state ^o, i e- the set of traces of the FSM A, for 
short. As usual, to represent the set of traces of an FSM we use the notion of a finite 
automaton. 

A finite state automaton, often called an automaton throughout the paper, is a 
quintuple P^{S, V, Sp,So,Fp), where 5 is a finite nonempty set of states with the initial 
state s'o and a subset Fp of final (or accepting) states, V is an alphabet of actions, and 
Sp^SxVxS is a transition relation. We say that there is a transition from a state ^ to 
a state S' ' labeled with an action v, if and only if the triple (s, v, s ') is in the transition 
relation Sp. The automaton P is called deterministic, if for each state se S and any 
action veV there exists at most one state s', such that (s, v, s')e c5/>. If P is not 
deterministic, then it is called nondeterministic. As usual, the transition relation dp of 
the automaton P is extended to sequences over the alphabet V. These sequences are 
usually called traces of the automaton P. Given a state s of the automaton P, the set of 
traces Tp(s)= V IBs'gFV ((s, «,s')g ^p)} is called the language generated at the 
state s. The language, generated by the automaton P at the initial state, is called the 
language generated by the automaton P and is denoted by Lp, for short. 

Given an FSM A = {S, I, O, Ta, sf), we derive the automaton Aut(A) = (Su(SxI), luO, 
Sp, So,Fp=S) [26] with the language that coincides with the set of all traces of the 
FSM. Each transition (^„ i,o, Sj) in Ta is represented by the two consecutive transitions 
(Si, i,(Si,i)) and ((sJ), o, Sj) in P. That is the automaton is obtained from the original 
FSM by replacing each edge labeled by Ho with an edge labeled by i, followed by a 
new non-accepting state, followed by an edge labeled by o. All original states are 
accepting. If the FSM A is observable then the automaton Aut(A) is known to be 
deterministic. 

Let A = (S, I, O, Ta , sf) andB^{Q, I, O, Tp, qo) be two FSMs, state q of FSM B is 
said to be a reduction of state ^ of FSM A = {S, I, O, Ta , sd) (written q < ^), if Trpiq) 
c TrA{s). States q and ^ is said to be equivalent (written q = s) if g ^ and s<q\ 
otherwise, states q and s are not equivalent. Moreover, 7? is a reduction of FSM A, if 
Trg c Tca- If Trp = Tca then FSMs A and B are equivalent, written as A = B. For 
complete deterministic FSMs the reduction and the equivalence relations coincide. 

A non-deterministic automaton can be converted into a deterministic automaton 
with the same language [9]. For this reason, we consider only observable FSMs. If an 
FSM is non-observable then it can be transformed into an equivalent observable FSM 
by determinizing the corresponding automaton. Given a deterministic automaton 
P^(R,IuO, Sp, ro,Fp) with the set of traces that is a subset of (lO)*, P can be 
converted into an observable FSM FSM(P) over input alphabet / and O if for each 
trace aio g Trp the prefix a also is a trace of the automaton P. States of the FSM{P) 
are the initial state and all accepting states of the automaton P. Let 
P^{R, V, Sp,ro,Fp) and R^{Q, W, SR,qo,Fp) be two automata. We further describe 
some operations over finite automata that will be used throughout the paper. 

Intersection. If alphabets V and W intersect then the intersection PnT? of automata P 
and R is the largest connected sub-machine of the automaton {S x Q, Vn W, S, 
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(so,qo),FpXFn). Given an action ae Vn W and a state (r,q), there is a transition at the 
state (r, q) labeled with a, if and only if there are transitions at states s and q labeled 
with a, i.e. {{{r,q),a,{r',q')) \ (r,a, r')G dp a (q,a,q')e ^ The set of traces of the 
automaton Pr^R accepts the intersection of the sets Trp and Trp. If V and W are 
disjoint then intersection of P and R is not defined, since the alphabet of an automaton 
cannot be empty. 

Restriction. Given a sequence a over alphabet V and an alphabet U, the U -restriction 
of a is obtained by deleting from a all symbols that are not in U. If there are no 
symbols from U \n a then the [/-restriction of a is equal to the empty sequence £. 
Given an automaton P and an alphabet U, the U-restriction of P is the deterministic 
automaton Piu that is equivalent to the automaton {S, U, S, ^o, Fp), where 
S= {{r,u,r')\3 obV* (^{r,a,r')&Sp & (aiu=u))}. The set of traces of the 
automaton Puj is the set of [/-restrictions of all traces of the automaton P, i.e. is the 
set {«G U*\3/^eL{P) 

Expansion. Given an alphabet U, the U-expansion of P is the automaton 
P-\u={R,V(jU,S,ro,Fp), where S= Sp(j{{r,u,r)\re R & mg U\V). The automaton 
P^u is obtained from P by adding at each state a loop transition labeled with each 
action of the alphabet [/\ F. If [/ is a subset of V then the automaton P-tm coincides 
with the automaton P. Automaton P^u has the set of traces («g(Fu[/) |3 /i&Trp 
{air-P)}. 

2.2 Parallel Composition of FSMs 

We consider a system of two Communicating FSMs of the context FSM Context={S, 
IvjV, OvjU,Ta,Sq) and of the embedded FSM Emb={T, U, V,Tg,tQ), as shown in Fig. 1. 
above. The alphabets / and O represent the external inputs and outputs of the system, 
while the alphabets V and U represent the internal interactions between the two 
machines. As usual, for the sake of simplicity, we assume that the sets /, O, V, U are 
pair-wise disjoint. The system produces an output in response to each input. We 
assume that the system at hand has at most one message in transit, i.e. the next 
external input is submitted to the system only after it produces an external output to 
the previous input. Under these assumptions, the collective behavior of the two 
communicating FSMs Context and Emb can be described by an FSM as follows [26]: 



I 

o 



Context 



u 



Emb 



Fig. 1. Parallel Composition of two FSMs 
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First, we transform the two FSMs Context and Emb into the eorresponding 
automata Aut(Context) and Aut(Emb). Then, we derive the automaton Aut(Context) 0 
Aut(Emb) = (Aut(Context) n Aut{Emb)'[i^o)iiyjo- Then, we interseet Aut(A) 0 Aut(B) 
with the automaton of the ehaos FSM defined over the alphabet I(jO. The obtained 
automaton is shown to have an FSM language over the alphabets / and O [26]. The 
FSM eorresponding to the obtained automaton is ealled the parallel composition of 
FSMs Context and Emb, and is written as Context 0 Emb. In this paper, the eontext 
and the embedded FSMs are assumed to be eomplete and deterministie. 

As an example, eonsider the two FSMs shown in Figures 4.1 and 7, respeetively. 
The set of external inputs is 7= {x\, X 2 ), the set of external outputs is O = {o\, 02 , 03 }, 
the sets of internal interaetions are F={vi, V 2 } and 7 /={mi, M 2 }. The eorresponding 
eomposed FSM is shown as the speeifieation FSM Spec in Fig 3.1. 

2.3 Testing in Context 

Testing in eontext deals with the generation of tests for implementations of the 
embedded maehine Emb assuming that the implementation of the eontext maehine is 
fault free [20, 18]. Moreover, usually it is assumed that the implementation system 
has been tested w.r.t. liveloeks, for example, as proposed in [7], and found to be 
liveloek free; thus, the system under test Context 0 Imp, where Imp is a eomplete 
deterministie implementation of Emb, is assumed to be eomplete and deterministie. 
Under these assumptions embedded implementations are tested w.r.t. external 
equivalenee or equivalenee in eontext. 

Given eomplete deterministie FSMs Context^{S, luV, OuU, T^, Sq) and embedded 
FSM Emb ^{T, U, V, Tb, to), let the eomposed FSM Context 0 Emb be also 
deterministie and eomplete. FSM Imp = {Q, U, V, Tb, qo) is said to be externally 
equivalent (or equivalent in the context) to the embedded FSM Emb if the FSMs 
Context 0 Emb = Context 0 Imp are equivalent, i.e. Context 0 Emb = Context 0 Imp. 

A test suite TS w.r.t. external equivalenee is a set of external input sequenees 
defined over the alphabet 7. Given a set 91 of possible implementations of the 
embedded maehine Emb, ealled the fault domain of Emb, a test suite TS is said to be 
complete w.r.t. the fault domain 91 if and only if for eaeh FSM Imp of 91 sueh that 
Context 0 Imp is not equivalent to Context 0 Emb, there exists a test ease in TS that 
eliminates Imp. 

Several fault models have been proposed for testing an embedded FSM w.r.t. 
external equivalenee [18]. For example, one ean explieitly enumerate all possible 
implementations of the embedded eomponent if the number of these implementations 
is not huge. When the fault domain is huge, one ean use for test derivation the 
methods that generate tests without the explieit enumeration of the fault domain 
maehines. For instanee, the W-method [5] and its modifieations, namely the Wp, 
UIOv, and the FIIS methods, ean be used if an upper bound on the number of states of 
an implementation system is known. In this ease, tests are derived without taking into 
aeeount the faet that the eontext is assumed to be fault free. Thus, the eonsidered fault 
domain ineludes all possible implementations of the embedded and eontext maehines. 
Therefore, in this ease, the derived tests are known to be redundant and an 
optimization proeedure sueh as that proposed in [25] is needed to reduee redundant 
tests. As an alternative approaeh, one ean eonsider as a fault domain for the embedded 
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machine, the set of all submachines of an appropriate nondeterministic FSM. This 
non-deterministic FSM is combined with the context machine and a test suite is then 
derived from the obtained Mutation Machine (MM) [28]. Flowever, a mutation 
machine is known to have infeasible machines that do not correspond to any possible 
implementation system. The number of these machines can still be large even if we 
decrease their number by using several mutation machines as done in [8, 7]. In order 
to avoid fault domains with infeasible machines, one can use as a fault domain for the 
embedded machine the largest solution M to the equation Context (> X = Context 0 
Emb. A complete deterministic implementation FSM Imp is not externally equivalent 
to the specification embedded machine Emb if and only if Imp is not a reduction of M 
[20]. Therefore, we can derive a complete test suite from a largest solution M w.r.t. 
the fault domain 91 and the reduction relation. Flowever, in this case, the sequences of 
an obtained test suite are defined over the internal alphabets U and V and thus, have to 
be translated to tests defined over the external input alphabets (i.e. external tests). In 
[20] some adhoc recommendations for such translation have been proposed. In the 
following sections, we propose a rigorous equation solving based approach for 
translating internal tests to external ones. 

3 Translating Internal Tests by Equation Solving 

In this section we use equation solving for translating internal tests of an embedded 
machine into external ones defined over the external input alphabets of the system. 
First, in subsection 3.1, we present a method for solving an FSM equation [3, 21], 
assuming that the internal interactions between the system components are 
unobservable, then, in subsection 3.2, we propose a method for translating internal 
tests by solving an appropriate automata equation. 

3.1 Solving an FSM Eqnation 

We consider the equation Context 0 A s Spec, where Spec = Context 0 Emb. We 
recall that this equation has a largest solution M that contains all possible 
implementations that are externally equivalent to the embedded component Emb. 

An FSM B over the alphabets U and V is called a solution to the equation Context 0 
X = Spec if Context 0 B = Spec. A complete solution M is called largest if it includes 
as its reductions all complete solutions to the equation Context 0 A = Spec, i.e. each 
solution to the equation is a reduction of the largest solution. In order to derive M, we 
use the methods proposed in [3, 21]. 

We replace the FSMs Context and Spec with the corresponding automata 
Aut(Context) and Aut{Spec) and solve the automata equation Aut(Context) 0 X = 
Aut(Spec). Since we are interested in an FSM solution, we derive the largest 
automaton with the set of traces that is a subset of (CIV)*. Thus, we derive as a largest 
solution the largest reduction of the automaton Aut{Chaos-UV), where Chaos-UV = 
{R,U,V,Tch, ro) is the chaos FSM over the alphabets U and V. 

Similar to [3] we first derive the automaton A(Aut(Context), Aut(Chaos-UV), 
Aut{Spec)) = Aut(Context)r\Aut(Chaos-UV)'ii.^oi^Aut(Spec)'tuuv- A state (s,r,q) of 
the automaton is called forbidden if the external restriction of the language generated 
at state {s,r,q) is not equal to the language generated at state q of the specification 
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Spec. We restrict the automaton to the alphabets U and V of the embedded FSM, 
replace each subset that has a forbidden state with the designated state ‘FAIL', and 
then convert the obtained automaton into an FSM defined over the alphabets U and V. 
Each undefined transition in the obtained FSM is specified as a transition to the DNC 
(don't care or chaos) state, and the ‘FAIL' state and its incoming and outgoing 
transitions are deleted. The DNC state accepts all input/output sequences of the set 
(UV)*. The largest complete submachine of the obtained FSM (if it exists) is the 
largest complete solution M to the FSM equation Context () X = Spec. In our case, M 
always exists since the equation has a solution, in particular the embedded component 
FSM Emb is a solution to the equation. In the following subsection we illustrate the 
above steps through an application example. 

3.2 Translating Internal Tests 

Given the largest complete solution M to the equation Context (> X = Spec, consider a 
complete test suite TS derived from M w.r.t. the fault domain 91 and the reduction 
relation. The sequences of TS are defined over the internal alphabet U. A test suite TS 
is said to be complete if for each implementation FSM Imp e i^that is not a reduction 
of M, there exists a test case aeTS s.t. the set of output responses of the FSM Imp to 
a is not a subset of the set of output responses of M to a. Since the FSM Imp is 
deterministic, the latter means that if the implementation FSM Imp is not a reduction 
of M, then there exists an input sequence ae TS s.t. the trace of FSM Imp with the U- 
restriction a does not intersect the set of traces of M with the t/-restriction a. Based 

on the complete test suite TS, we derive the set TS of input/output sequences of the 

set (UV)* such that the set TS intersects the set of traces of each possible 
implementation Imp e 91 that is not a reduction of M. For each non-empty prefix wiVi 
. . . UkVk of each trace of the set {p-. Traces of M & /Iiu e TS} we include into the 

set TS the set of sequences {wiVi . . . UkV : u\V\ ... UkV i Traces of M] (if it exists). 

Proposition 1. Given a largest solution M to the equation Context (> X = Spec. An 
implementation FSM Imp e 91 is not a reduction of M if and only if the set of traces 

of Imp intersects the set TS . 

According to the above proposition, if an implementation FSM Imp e 91 has a 

trace of the set TS then Imp is not externally equivalent to the embedded machine 

Emb. The traces of the set TS can be represented as traces of an automaton , 

where each trace of TS leads to the designated Trap state of Aut TS . The state Trap 
is the only accepting state of the automaton and the language generated at the state 
Trap is the set (UV) . We obtain a test generator that generates all sequences over 
(lO)* such that for each Imp e 91 that is not externally equivalent to Emb, the 

generator induces in Imp at least one trace of the set TS in order to detect that Imp is 
not a reduction (i.e. Imp is a nonconforming implementation of Emb) of M,. Due to 
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the test arehiteeture shown in Figure 2 , the generator is obtained by solving the 
equation Aut{Context) OX = Aut TS . 
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Fig. 2. Test Architecture 



As an application example, consider the specification FSM Spec, shown in Fig 3 . 1 , 
defined over the inputs / = {x\, X2} and outputs O = {o\, 02, 03}. The corresponding 
automaton Aut{Spec) is shown in Fig 3 . 2 . Moreover, consider the context FSM 
Context, shown in Figures 4 . 1 , defined over the external inputs / = {x\, X2), external 
outputs O = {o\, 02, 03}, internal inputs F={vi, V2} and internal outputs U^{ui, M2}. 
The automaton Aut{Context) that corresponds to Context is shown in Fig 4 . 2 . 
Accepting states of both automata are shown by double lines. We are required to 
solve the FSM equation Context 0 X = Spec and obtain its largest solution M. This 
solution is defined over FSMs, thus it is a submachine of automaton Chaos-UV shown 
in Fig. 5 . In order to solve the equation, we combine the automata Aut(Spec) and 
Aut(Context) with Aut(Chaos-UV) and obtain the automaton A(Aut(Context), 
Aut(Spec), Aut(Chaos-UV)) shown in Fig. 6. Each state (s,j, Q) where the external 
restriction of the set of traces at the state does not coincide with the set of traces at 
state j of the specification, i.e. states h 3 A, m 4 A, n 3 A, c 2 A, and g 4 A are declared as 
the designated state "FAIL'. We restrict the automaton onto the alphabet {u\, M2, vi, 
V2} of the solution. Each subset of states of the restricted automaton that includes the 
"FAIL' state is designated as the "FAIL' state. We add the DNC state for the transitions 
(f 4 A, Ml) and (DA, mi) since there are no transitions from these states under the input 
Ml, delete the "FAIL' state with its incoming transitions and obtain the largest FSM 
solution M shown in Fig 7 . Then, we derive from M the complete internal test suite TS 
= {mi M2 M2, M2 M2} w.r.t. all FSMs with at most two states using the FIIS method [ 19 ]. 
The set of all traces of the FSM M with the [/-restriction in the set TS is {mi/vi M2/V2 
M2/V1, M2/V1 M2/V1}. According to Proposition 1 , if an implementation of the embedded 

component has one of the sequences of the set TS ^ {u\lv2, u\!v\ M2/V1; mi/vi M2/V2 
M2/V2; M2/V2; M2/V1 M2/V2} then this implementation is not externally equivalent to the 

specification of the embedded component FSM. We represent the sequences of TS 

as the finite automaton Aut TS shown in Fig 8 and solve the equation Aut{Context) 0 

X=AutTS . 
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When no access to the internal interactions is available, some faults of the 
embedded component become latent. To illustrate latent faults consider a faulty 
implementation Imp of the embedded component that has the trace M1V2 instead of 
MiVi. The trace M1V2 in the faulty implementation can be induced by the external input 
X2. However, when the internal outputs are unobservable, the composed system 
Context 0 Imp has the expected output response 02 to the input X2. In order to detect 
that Imp has the wrong trace M1V2, we have to apply after X2 the input Xi. In this case 
the composed system will reply with the unexpected output 02. Therefore, since the 
internal channels are unobservable, it is insufficient to have a generator that induces at 
least one forbidden trace of each non-conforming implementation of the embedded 
machine. The consequences of the fault have to be externally observable, i.e. have to 
be propagated to the external environment. In other words, a test generator has to be a 
reduction of the complement of the specification machine. 

Thus, when solving the equation Aut(Context) 0 X = AutTS we look for a 
solution that is a reduction of the complement of the specification machine Spec . 
This is done since an internal fault is detected if and only if an unexpected output is 
produced to some external test case. The following statement holds. 

Proposition 2. Given a solution Gen to the automaton equation Aut{Context) () X = 

Aut TS , let AutGen be a reduction of the automaton Aut{ Spec ) and have a finite 
number of traces. The /-restriction of the traces of the automaton AutGen is a 
complete (external) test suite w.r.t. the fault domain 91 and the external equivalence 
relation. 

In our application example we are interested in a largest solution to the equation 
Aut{Contexi) (> X = AutTS that is a reduction of Aut{ Spec ) of Fig 9. In order to 

obtain this solution, we derive the automaton A(Aut(Context), Aut( Spec ), Aut TS ) 
shown in Fig. 10. The language of the /-restriction of the obtained largest solution is 

Xi(X2Xi)*XiXi, (Xi(X2Xi)*Xi(X2Xi)*, X2X2(XiX2)*Xi, X2X1, X2X2X2*(XiX2)*, and 

correspondingly a reduction of this largest solution that has the sequences TS = 
{xiXjXi, X2X2X1, X2X1, X2X2X2} ( these sequences are the labels of all simple paths from 
the initial state of the reduction to a final state that includes the trap state R) is also a 

solution to the equation Aut{Context) () X = Aut TS .The external test suite TS is a 
complete test suite for the embedded component w.r.t. the external equivalence 
relation. 
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Fig. 10. Automaton A(Aut(Context), Aut( Spec ), Aut TS ) 



A Summary of the Fault Propagatiou Approach: 

luput: A deterministic Context^{S, luV, OuU,Ta,So), a deterministic embedded 
component Emb={T, U, V,TB,to), and a deterministic specification Spec ^{Q, 
I, 0,Tspec,q<^ ^ Context 0 Emb, and the fault domain 9t of the embedded 
component Emb. 

Output: A complete external test suite defined over the external alphabet / for testing 
the embedded component Emb. The test suite is complete w.r.t. the fault 
model <Context 0 Emb, = , Context 0 

Step 1 : Derive a largest FSM solution M to the equation Context 0 A = Spec. 

Step 2: Derive a complete test suite TS w.r.t. the fault model <M, <, 9i>. Then, 

derive from TS the set of sequences TS , over the alphabet {UV)*, that 
intersects the set of traces of each possible implementation Imp in 91 that is 

not a reduction of M. Represent the sequences of TS by the automaton 

AutTS . 
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Step 3 : Derive a largest solution AutGen to the automata equation Aut(Context) 0 X 

= AutTS that is a reduction of the automaton Aut(Spec ), where Spec is 
the complement of Spec. 

Step 4 : Derive an external test suite from the automaton AutGen by projecting 
AutGen on the external alphabet / and by considering in the obtained 
automaton all simple paths from the initial state to each final state that 
includes the trap state R. The labels of these simple paths form a complete 
(external) test suite for the embedded component Emb w.r.t. the external 
equivalence relation. 

4 Conclusion 

In this paper we presented an equation solving based approach for translating internal 
tests derived for a component embedded within a composite system into external tests 
defined over the external alphabets of the system. The system is represented as two 
communicating finite state machines, an embedded component machine and a context 
machine that represents the remaining part of the system. The context is assumed to 
be fault free. The method can be adapted for generating tests for a system of two or 
more communicating finite state machines. This is part of our current research work. 



References 

[1] G. Barrett and S. Lafortune, “Bisimulation, the supervisory control problem, and strong 
model matching for finite ftate machines”, Discrete Event Dynamic Systems: Theory 
and Application, 8(4), 377-429, 1998. 

[2] G. V. Bochmann and P. M. Merlin, “On the construction of communication protocols”. 
ICCC (1980) 371-378, reprinted in "Communication Protocol Modeling", edited by C. 
Sunshine, Artech House Puhl. (1981). 

[3] S. Buffalov, K. El-Fakih, N. Yevtushenko, & G.v. Bochmann, “Progressive solutions to 
a parallel automata equation”. In Proc. of the IFIP 23rd International Conference on 
Formal Techniques for Networked and Distributed Systems (FORTE 2003), Berlin, 
Germany, Published as LNCS 2767, pp.367-382, 2003. 

[4] Cavalli, , D. Lee, D., C. Rinderknecht, , and F. Zaidi, “Hit-or-Jump: An algorithm for 
embedded testing with applications to IN services”. Proceedings of Joint Inter. Conf. 
FORTE/PSTV99, pp: 41-58, 1999. 

[5] T. S. Chow, “Test design modeled by finite-state machines,” IEEE Trans. SE, vol. 4, 
no.3,pp. 178-187, 1978. 

[6] J. Drissi and G. v. Bochmann, Submodule Construction for systems of I/O Automata. 
Technical Report #1133, DIRO, Universite' de Montreal, Canada, 1999. 

[7] K. El-Fakih, V. Trenkaev, N. Spitsyna, N. Yevtushenko, “FSM Based Interoperability 
Testing Methods”, in Proc. of the IFIP 16th International Conference on Testing of 
Communicating Systems, Oxford, U.K., Published as LNCS 2978, pp. 60-75, 2004. 

[8] K. El-Fakih, S. Prokopenko, N. Yevtushenko, and G. v. Bochmann, “Fault diagnosis in 
extended finite state machines”, in Proc. of the IFIP 15th International Conference on 
Testing of Communicating Systems, France, published as LCNC 2644, pp. 197-210, 
2003. 

[9] I. E. Hopcroft, and I. D. Ullman, Introduction to automata theory, languages, and 
computation, Addison-Wesley, N.Y., 1979. 




Khaled El-Fakih and Nina Yevtushenko 



S. G. H. Kelekar, Synthesis of protocols and protocol converters using the submodule 
construction approach. In. A. Danthine et al, editors, Protocol Specification, Testing, 
and Verification- PSTVXIII, 1994. 

R. Hierons and H. Ural, “Concerning the ordering of adaptive test sequences”. In Proc. 
of the IFIP 23rd International Conference on Formal Techniques for Networked and 
Distributed Systems (FORTE 2003), Berlin, Germany, Published as LNCS 2767, 
pp.289-302,2003. 

Information technology. “Open systems interaction. Conformance testing methodology 
and framework”. International standard IS-9646, 1991. 

R. Kumar, S. Nelvagal, and S. I. Marcus. “A discrete event systems approach for 
protocol conversion”. Discrete Event Dynamical Systems: Theory and Applications, 
7(3) 295-315,1997. 

L. P Lima, , and A. R. Cavalli, “A pragmatic approach to generating test sequences for 
embedded systems”. Proceedings of 10th IWTCS, pp: 125-140, 1997. 

D. Lee, K. Sabnani, D. M. Kristol, and S. Paul, “Conformance testing of protocols 
specified as communicating finite state machines - a guided random walk based 
approach”. IEEE Transactions on Communications, 44(5): 631-640, 1996. 

P. Merlin and G. v. Bochman. On the construction of submodule specifications and 
communication protocols, ACM Trans. On Programming Languages and Systems. 5(1) 
1-25, 1983. 

J. Parrow, Submodule construction as equation solving in CCS, Theoretical Computer 
Science, 68, 1989. 

Petrenko, N. Yevtushenko, G. v. Bochmann. “Fault models for testing in contexf’, 
FORTE ‘96. 

Petrenko, N. Yevtushenko, and G. v. Bochmann. “Testing deterministic 
implementations from their nondeterministic specifications”. Proceedings of the IFIP 
9th International Workshop on Testing of Communicating Systems, Germany, pp. 125- 
140, 1996. 

Petrenko, N. Yevtushenko, G. v. Bochmann, and R. Dssouli, “Testing in context: 
framework and test derivation”. Computer communications, Vol. 19, pp. 1236-1249, 
1996. 

Petrenko and N. Yevtushenko, Solving asynchronous equations. In S. Bukowski, A. 
Cavalli, and E. Najm, editors. Formal Description Techniques and Protocol 
Specification, Testing, and Verification- FORTE XI/PSTVXVIII ‘98, Chapman-Hall, 
231-247, 1998. 

Petrenko, N. Yevtushenko, A. Lebedev, and A. Das, “Nondeterministic State Machines 
in Protocol Conformance Testing,” Proc. of the IFIP 6th IWPTS, France, pp. 363-378, 
1993. 

H. Qin and P. Lewis, Factorisation of finite state machines under strong and 
observational equivalences. Journal of Formal Aspects of Computing, 3, 284- 307, 1991. 
Z. Tao, G. V. Bochmann and R. Dssouli, A formal method for synthesizing optimized 
protocol converters and its application to mobile data networks. Mobile Networks & 
Applications, 2(3) 259-69, 1997. 

N. Yevtushenko, A. R. Cavalli, and L.P. Lima, “Test minimization for testing in 
context”. Proceedings of the 1 1th IWTCS, pp: 127-145, 1998. 

N. Yevtushenko, T. Villa. R. K. Brayton, A. Petrenko, A. Sangiovanni-Vincentelli. 
Solution of parallel language equations for logic synthesis. In Proc. of the International 
Conference on Computer-Aided Design, 103-110, 2001. 

W. M. Wonham and P. J. Ramadge, On the supremal controllable sublanguage of a 
given language. SIAM J. Control. Optimization. 25(3) (1987) 637-659. 

K. El-Fakih, N. Yevtushenko, and G. v. Bochmann,“Diagnosing multiple faults in 
communicating finite state machines”. In Proc. of the IFIP 2 1st International Conference 
on Formal Techniques for Networked and Distributed Systems (FORTE 2001), Cheju 
Island, Korea), pp. 85-100, 2001. 




Automatic Generation of Run-Time Test Oracles 
for Distributed Real-Time Systems * 



Xin Wang, Ji Wang, and Zhi-Chang Qi 



National Laboratory for Parallel and Distributed Processing 
300 Lichen Rd., Changsha, 410073 China 
xinwang? 6@yahoo .com.cn, j i . wang@263 . net 



Abstract. Distributed real-time systems are of one important type of 
real-time systems. They are usually characterized by both reactive and 
real-time factors and it has long been recognized that how to automati- 
cally check such systems’ correctness at run time is still an unaddressed 
problem. As one of the main solutions, test oracle is a method usually 
used to check whether the system under test has behaved correctly on 
a particular execution. Test oracle is not only the indispensable stage of 
software testing, but also the weak link of the software testing research. 
In this paper, real-time specifications are adopted to describe the proper- 
ties of distributed real-time systems and a real-time specification-based 
method for automatic run-time test oracles generating is proposed. The 
method proposed here is based on tableau construction theory of real- 
time model checking, automatically generates timed automata as test or- 
acles, which can automatically check system behaviors’ correctness from 
real-time specifications written in M/TL[o,d]. 



1 Introduction 

With the development of the network, distributed computing has become the 
mainstream of the computing technology undoubtedly. As a special kind of real- 
time systems. Distributed Real-Time Systems (DRTS) built on network environ- 
ment have been applied widely in industry, military and commercial high-tech 
areas, especially in power engineering, aviation, real-time control systems, flex- 
ible manufacturing system, vision systems, etc [1]. Most of DRTS require high 
safety and strict time constraints, though the complexity of DRTS spans the 
gamut from very simple control of laboratory experiment, to very complicated 
projects such as the fighter avionic. So they are new challenge to the software 
testing methods during the software development. 

Test oracle is a method for checking whether the system under test has 
behaved correctly on a particular execution [2]. It is the indispensable stage of 
software testing and also the weak link of the software testing research. The 
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correctness of DRTS depends not only on the logical result of the computation, 
but also on the time when the results are produced [3]. Using run-time test 
oracles can not only check whether the system run is correct, but also improve 
the efficiency of software testing, set free testers from heavy work of checking 
system results. 

DRTS are usually command-control systems, so their primary characteris- 
tics are event-triggered, complex event sequences, and real-time, precise time 
constraints. Temporal logic is the most important formal specification that de- 
scribes distributed event-triggered, real-time systems’ properties, and is used 
widely during software development. Using test oracles generated from tempo- 
ral logic can reduce the costs of rewriting specifications greatly. The properties 
about time constraints of DRTS that described by real-time temporal logic are 
called real-time specifications. Test oracles generated from real-time specifica- 
tions can automatically check if the run sequences of tested systems satisfy their 
specifications, if not, they can report corresponding error information. 

The method proposed here is based on tableau construction theory of real- 
time model checking [4], automatically generates timed automata as test ora- 
cles, which can automatically check system behaviors’ correctness, from real-time 
specifications written in MITL^Q ^iy The remainder of this paper is organized as 
follows. Section 2 describes relevant methods of automatically generating test 
oracles for reactive, real-time systems and their relative merits. Section 3 intro- 
duces the logic and timed automata that we use. Section 4 gives two approaches 
to acquire the traces of distributed real-time systems as input of test oracles. 
The work presented in core section 5 represents the method of automatically 
generating test oracles and case study. Section 6 concludes this paper and points 
out future work. 



2 Related Work 

Based on the generic tableau algorithm that generates specification automata 
for model checking, Dillon and Yu have proposed an automata-based method 
that can translate a temporal logic formula into a finite state machine as a test 
oracle [5, 6]. Once an execution sequence of a program is put into the finite state 
machine, the finite state machine can check if this execution sequence satisfies 
its specification. Proposition temporal logic can be applied only to describe the 
properties of reactive systems, but not real-time systems, because it doesn’t 
support time quantifier. Therefore, this method can only be applied to reactive 
systems. 

Method proposed by Geilen [7] also comes from the idea of model checking, 
which is very similar with the algorithm proposed by Kupferman and Vardi. 
This method has on-the-fly feature and has the same applicability as Dillon and 
Yu’s. 

Temporal assertions are proposed by Doron Drusinsky of Time-Rover 
Press [8] . The main idea is that temporal logic formulas are translated into some 
special kind of assertions (i.e. temporal assertions) as test oracles. Assertions 
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are inserted into a tested program manually in order that they can automati- 
cally check the program’s correctness at run time. Assertion preprocessor must 
insert sub-assertions (assertions get by decomposing temporal assertions) into 
all related positions and maintain the relationship among them at run time. 
The costs of assertion maintenance will seriously influence the run of real-time 
systems and lend to the violation of time constraints, thus this method is more 
perfect for reactive systems or real-time simulators that amplify the absolute 
time than real-time systems. 

John Hakansson has given an on-line test oracle generation method that is the 
only one that can check the correctness of real-time systems at run time [9] . Based 
on the rewriting rules of safety properties of real-time systems, this method dis- 
cretizes the continuous time and automatically generates test oracles to monitor 
systems’ behaviors externally. The test oracles fetch system data through sam- 
pling corresponding signals externally and compute the state-of-the-art pattern 
of systems at every end of the cycles, and in this way this method can support 
relatively strict time constraints. Because time is discretized, some system be- 
haviors may be lost or some wrong behaviors may not be checked out if the time 
constraints in specifications are not integral multiple of read cycle. 

3 Preliminaries 

This section introduces the propaedeutics about logic and automata that we will 
use when automatically generating test oracles from real-time specifications. 

3.1 Timed State Sequences 

Let time domain be the non-negative real number set R>q. An interval / is 
a convex subset of R>o, which has the form [a, b) where a, b€R>o and a<b. For 
a finite interval /, let /(/) and r{I) denote the left and right end of / respectively, 
and |/| denote the length of I. Two intervals I, I' are adjacent if and only if 
r{I) = 1{I). We use t -I- / to denote the interval {t + Let P be a flnite 

proposition set and state s be a subset of P. If sCP and p Ss is a proposition 
in s, s is called p-state, denoting as s \=p. 

Definition 1. [10] A state sequence s = sqS\S 2 - ■ ■ is an infinite sequence of 
states SiQP. An interval sequence I = / 0 / 1 / 2 . . . is an infinite sequence of timed 
interval such that 

[Initiality] Iq is left-closed and 1 {Iq) = 0; 

[Adjacency] for all i>0, the intervals R and R+i are adjacent; 

[progress] every time tGR>o belongs to some interval R. 

A timed state sequence r = (s, /) is a pair that consists of a state sequence 
s and an interval sequence I. 
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3.2 Real-Time Logic AL/TL[o,d] 

MITL is a kind of linear temporal logic that is interpreted over timed state 
sequence [10]. In this paper, we only consider the real-time specifications written 
in M/TL[o^d](dGi?>o), a restrict version of MITL. 

Definition 2. The formulas of MITL^Q f^^ can be inductively defined as follows: 
(f ::= true\ p | -’(^ | A | 4’iU[o,d]4>2 

The semantics of MITL^q j^ is presented in [10]. 

We also use dual operators “V” and “F” to define </)i V ^2 — A -’</> 2 ) 

and 0iV[o_d]02 — Similar with the “Always (‘D’)” and “Some- 

time (‘0’)” operators in LTL(Linear Temporal Logic), we use operators “Always 
in the interval [0,d] (‘□[o,d]’)” “Sometime in the interval [0,d] (‘<}[o.d]’)” to 
define □[o,d]<?i’ =falseV[o^d](l> and <}[o,d]4> =trueU[o^d]cl). 

Definition 3. [10] Let </> he a formula of MITL^^ d]- kFe call interval sequence 
I is (p-fine if for every sub-formula i] of (j), every k>0 and every ti,t 2 € I{k), 
\= i] if and only if ]= ip. We call a timed state sequence r = (s, /) is 
(p-fine if the I in (s, I) is (p-fine. 

In [11], Lemma 4.11 is shown that the intervals of any timed state sequence 
can always be refined to be fine for any MITL formula. It holds for the subset 
of MITL, MITLffl d] too. 

The tableau construction theory of real-time model checking requires that 
the truth value of the formulas interpreted over the time state sequence (s, /) 
can’t change during a single interval of I, i.e. the timed state sequence (s, /) 
must be 0-fine. 

3.3 Timed Automata 

The test oracles studied here are a variant of timed automata originally proposed 
by Alur and Dill [11] to serve as our test oracles. Timed automata use clocks 
whose values are positive real number to record the points when real-time speci- 
fications become true and when states change. Give a clock set C, clock interpre- 
tation function vGCInt{C) and clock setting function CS G Cset{C) are partial 
mappings from C to i?>o- For some d G R>o and every x G dom{v), v-\-d denotes 
the clock interpretation that assigns v{x) -I- d to any clock x in the domain of v, 
and CS{v) denotes that C5'(a;)(if defined)or v{x) is assigned to CS{v){x). For a 
subset 7 of C, we use CS[y := n] to denote the clock setting that maps all clocks 
in 7 to n and keeps other clocks unchanged. Clock condition set CCond{C) over 
clock set C \s {x ■.= t,x > d,Q <t < d,x < t < d-\- x,y := t — X \ x,y,t G C}. 

Definition 4. Let P he a priority function. For a set I = {ci, C 2 , . . .Cn} 
(iGN, CiGCCond{C)) and the natural number set N, we define: 

• sorting function o : L-^ < > for irG{l,2, . . .n} such that for ev- 

ery t<ir^isl£n, P{ci^)<P(cif) holds or their is no comparability between Ci^ 
and Ci^ ; 
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• o’s inverse function o ^ : {ci,C 2 , . . such that o o(/) = I. 

Definition 5. Let P he a set of proposition constraints. A finite-input timed 
automaton < S, Sq, C, Q, CC, OCC, Tran, Se > over P is defined as follow: 

• S is a finite set of states; 

• C is a finite set of clocks; 

• So is a finite set of initial extended states, (so,vo)GSo^SxCTnt{C); 

• Q : is a state labelling function which maps a state to a proposition 

constraint subset, i.e. Q{s)C2^; 

• CC : is also a state labelling function which maps a state to 

a clock condition subset; 

• OCC : is an another kind of state labelling which maps 

a state to an ordered clock condition subset; 

• TranCS x CSet{C) x S is a set of transitions, each of which labels with 
a clock setting function; 

• Se G S is a set of finite states. 

Definition 6. A run of a finite-input timed automaton < S, So, C, Q, CC, OCC, 
Tran, Se > is a finite sequence -^(sq, • '~^(sr, U) — '^(sn,tn) 

70 71 72 'Ir 7»-+l 7n 

of states SiGS (0 < i < n), clock t G C, clock sets ji C C and a sequence of clock 

interpretation function v = (vq, vi, ... , w„_i) satisfying the following constraints: 

• ('^Ojtlo) G So, Sji G Se, 

• For every 0 < k < n, there exists some {sk, CSk+i, Sk+i) such that for every 

cGC, 



i tk+\ C t 

CSk+i[lkJri •= 0](c) t and CS(c) is defined ; 

Vk{c) otherwise 

• For every 0 < k < n, every c G C, Vk{c) satisfies CCk(sk) and OCCk(sk). 

Definition 7. Let r = (s, /) be a timed state sequence and he 4>-fine, A is 
a finite-input timed automaton < S, Sq,C,Q,CC, OCC, Tran, Se >• We say 
that T = (s, I) can he accepted by A, if: 

• for e — > 0-1- there is some r G N such that -^(so,r(/o) — e)— ^(si, r(/i) — 

C 71 

e)^- — ^{sr, r{Ir) — £) is a run of A; 

72 7r 

• for every k G Z~^ , we have Sk C Q[u{k)) if u{k) is a state of A which 
corresponds to the k-th position of the above run. 

In fact, the acceptable input of a timed automaton is not timed sequences, 
but the sequences of state-time pairs like (sqSi . . .Sn,toti . . .tn). Thereby, we 
must translate the timed state sequences into the above format. With this end 
of view, we introduce s{£ 0-I-) and use r{Li) — e to replace the right end of 
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the interval li. In the field of real number, it is not holds to treat r{Ii) — e as 
the right end of li, because no matter how close e approximates to zero, e/2 < e 
always holds. But from the fact that the run of computers is step by step, i.e. 
the time is discrete, the interval {r{Ii) — e,r{Ii)) doesn’t exist if the value of e 
is small enough, such as let e equal to or smaller than the minimal click of the 
clock in a real-time system. 



4 Traces Acquisition from DRTS 

The behaviors that we want to acquire from DRTS are decided by the atomic 
formulas of real-time specifications. There are only two methods that can acquire 
the behaviors of DRTS and their occurring time; one is acquiring traces from 
outside of DRTS, another is acquiring traces from inside. 

If all system behaviors involved by real-time specifications can be detected 
from outside of the DRTS, the first method can be used. Some kind of program 
module serves as monitor, detecting observable signals from outside of systems 
periodically and sending them to test oracles. The point when the output signals 
change is the left end of interval, and the point when the output signals change 
next time is the right end of interval; the interval is left-closed and right-open. 

If real-time specifications involve internal states of systems, the second 
method must be used, i.e. some kind of assertions are inserted into proper posi- 
tions (such as where the related states maybe change) of DRTS; assertions will 
send the information on which states change and when they change as soon as 
the true value of assertions change to test oracles. The point when the output 
signals change is the left end of interval, and the point when the output sig- 
nals change next time is the right end of interval; the interval is left-closed and 
right-open. 



Example: We consider the Carrier Sense, Multiple Access with Collision De- 
tection protocol, or CSMA/CD for short [12, 13] which is widely used on LANs 
in the MAC sublayer. One safety property of CSMA/CD can be described as 
□ [o^oo]((2^’'a’T-sl A Trans2) => 0 [g ^jco/Z) written in MITL that means whenever 
both senders begin transmitting, a collision is inevitably detected within cr. The 
value of varies with the network on which the protocol runs. For instance, for 
a 10 Mbps Ethernet with a typical worst case round trip propagation delay of 
51.2/rs, we set a to be 25.6/is. We can get three system events from the above 
property: Transl, Trans2 and coll. 

Fig.l is the oscillogram of Transl, Trans2 and coll. While the three traces 
come to test oracles, one part of test oracles must arrange them into one trace 
according to the time they happen and assure the trace is (p-fme. Suppose that 
the vertical dash lines denote the right end of the refined intervals, we can get 
following timed state sequence from Fig. 1: 

{{^Transl, ~^Trans2, ~^coll}[0, ti)) {{^Transl, ~^Trans2, ^coU}[ti, ^ 2 )) 

({Transl, ~^Trans2, -^coll}[t 2 , t^)) {{Transl,Trans2, -^coll}[t 3 , ti)) 
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Fig. 1. The oscillogram of events Transl, Trans2 and coll 



{{Transl, Trans2, ^coll}[t/^, ^ 5 )) {{-^Transl, Trans2, -^coll}[t 5 , to)) 
{{^Transl, Trans2, coll}[tQ, ^ 7 )) ({Transl, Trans2, coliyit-j, fg)) 

{{Transl, Trans2, coU}[tg,, tg)) {{Transl, Trans2, ^coll}[tg, fio)) 
{{^Transl, Trans2, -^coll}[tio, in)) . . . 

The refinement procedure is done from the inner sub-formulas to outer sub- 
formulas, which give in [10] . In out example, as long as we get an event, we should 
refine the interval of coll first, then refine the interval of Transl A Trans2 and 
the refined interval of coll. In this way, one interval may be cut into several 
smaller intervals which act as the actual input of the test oracles. 

In this example, there must be three assertions corresponding to the three 
events. The assertions should be put on the neck of the statements that can 
cause the event status to change, such as readin, assignment, output statement 
and etc. In each of the assertions, there must be two variables to record the value 
before the current point and at the current point respectively. When the values 
of the two variables don’t equal, the assertions should output the current values 
of the events and the time acquired from the system clock or specific external 
clock. 

5 Automatic Generation of Run-Time Test Oracles 

Generating run-time test oracles automatically is to construct timed automata 
based on real-time specifications written in M/TT[o_d]. Differing from speci- 
fication automata in real-time model checking, the automata constructed for 
software testing need only accept finite state sequences. We say that a timed 
state sequence satisfies its specifications if this timed state sequence can reach 
the final states of automata constructed based on its specifications, i.e. it can 
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Fig. 2. The role of test oracle in software testing 



pass through test oracles. The role of test oracles generated by our method in 
software testing is represented in Fig. 2. 



5.1 Rewrite Rules 

The procedure that generates automata automatically from logic formulas often 
has to use rewrite rules. Based on rewrite rules, a logic formula can be equiva- 
lently decomposed tow parts: constraints that can be computed in current state 
and constraints that will be computed in subsequent states. Rewrite rules usu- 
ally use “O” operator to denote the constraints that will be computed in the 
subsequent states. In order to express the constraints that will be computed after 
some time point in we define similarly operator “Q” and extend the 

syntax of M/TL[g 



Extended Af/TT[o,d] In order to rewrite the formulas of MITL^q ^], we use 
“O” operator, clocks, clock conditions and clock interpretation function to ex- 
tend the syntax and semantics of basic M/TL[o^d]- 

Definition 8. Based on the formulas of basic MITL^q ^i]! the formulas of 
EMITL\f) fi^ can he defined inductively as follows, where 4>, 4>i and ^2 are for- 
mulas of MITL^q j^, X and t are clocks, d S 

(fi ::= <f> \ ipi \/ if 2 \ ^p\ l \^^2 I CS.'-p I a:>c? | 0<t<d \ x<t<x d \ x := t \ y \= 

t-x \ I (^lV[ 0 ,d ]*<^2 I 4>l^[x,d]^2 I 4>lV[y,d]„,4>2 \ 0‘P 

Definition 9. The satisfiability relationship t |=„ (f denotes that the timed state 
sequence r satisfies 4> in context of the clock interpretation v. The semantics of 
EMITL^O fi] is extended as follows: 

• T \=y (j) iff T \= (j); 

• T \=y \/ (f 2 iff T \=y tpi or T \=y (fi2 

• T \=y ifi Aip 2 iff T \=y (pi and r |=„ (fi2; 

• r\=y CS.ip iffr |=CS(,;) Ti 

• T |=„ X > d iff v{x) > d; 
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Table 1. Rules for decomposing a basic formula tf) 



4> = 


U {</<} reduces to 


4>iE4>2 




4>lA(j}2 


u {01, 02} 



• T |=„ 0 < t < d iff 0 < v{t) < d; 

• T |=„ x<t<x + diff v{x) < v{t) < v{x) + d; 

• T \=y X :=t iff v{x) := v{t); 

• T y.= t - X iff v{y) := v{t) - v{x); 

• T |=„ iff there is some di G [t>(a;), t;(a;) +d], such that \=v+di 

4>2 and for every c?2 S [v{x),di], \=v+d2 </'i/ 

• T \=y 4>iyix,d]4>2 iff for every di G [v{x),d], \=v+di 4>2, or there is 
some d2 G [t;(a;), di], such that \=v+d2 (fi; 

• T |=„ (^iV[o_d ]^02 iff for every di G [v{x),v{x) + d], hi^+di 4>2, or there is 

some d2 G such that \=v+d2 </>i; 

• r <fiV[y^d]^(j)2 iff for every di G +v{y),v{x) + d], \=v+di (t>2, or 
there is some d2 G [f(a;) + v(y), di], such that \=v+d2 4 >i; 

• T\=yOif iff{s\i^) h«-t|/oi 

For a basic formula of M/TL[o_d], we use operator “V” and “V[o,(i]” to push 
all negations inward until they reach atomic propositions. When mentioning 
the basic formulas of MITL\^Q d] iii r^st of this paper, we mean the formulas of 
MITL^q j^ whose negations have been pushed inward. 

Then we must define the clocks for the temporal operators in basic MJTLjg 
formulas. The decomposition rules is presented in Table 1 for a basic MITL^^ d] 
formula </>, S' e {C/[o.d], V[o,d]} and A G {A,V}. 

Definition 10 . Let <f be a basic MITL]f) d] formula. The set of the clocks of the 
temporal operators in 4> can be defined recursively using following steps: 

1 . Let (pQ = { 4 >}. As long as one of the rule in Table 1 can be applied to any 
terms in <L>n, then apply one to a term to obtain ^n+i- When no more rules 
can be applied, we get a set of sub-formulas of </>. Ln this set, each element 
either is a proposition, or has a temporal operator as outermost operator. 

2 . For each element whose outermost operator is a temporal operator, we de- 
fine a clock X for the outermost temporal operator and an null ancestor set 
AncSetx for every clock. 

3 . For each element ip in d>n^i, let <Pq = {g}\, 1^2} cmd repeat step 1 if its form 
is ipiAip2- As a result, we will get a set similar to the one in step 1 . For each 
element which has an outermost temporal operator, the clock of its outermost 
temporal operator is y \x if the clock of the operator S is x, i.e. a clock y 
whose value is relative to clock x, the ancestor set of the clock AncSety equals 
{cc} U AncSetx. 

4. Repeat step 3 until all elements of all sets generated by these steps are propo- 
sitions. 
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Rewrite rules The aim of using rewrite rules is to transform a basic M/TL[g 
formula (f> into normal form: (j) = \/ CSi.{cCi Acj)iA Ov^i)j where CSi denotes that 

i 

current clocks are set by clock setting function, cci are conjunctions and “ordered 
conjunctions” of clock conditions, 4>i are conjunctions of atomic propositions, and 
<Pi are subsequent formulas, i.e. conjunctions of EMITL^q j^. 

While constructing timed automaton, we use triple < CS, Now, Next > to 
denote cj) = \f CSi.{cci A (j)i A Q(pi), where CS denotes the labels of transitions, 

i 

Now includes clock conditions and propositional /pi that must be satisfied in cur- 
rent state, and Next includes subsequent formulas that will be satisfied. The data 
structure of Now is the same as the labels of the states of the timed automata, 
i.e. Now =< D,E >, where D is a set of clock conditions and propositions, E 
is an order set of clock conditions. Thereby, we must define the priorities for the 
clock conditions. 

Definition 11 . A priority function P : CCond{C) x CCond{C) {>} is de- 
fined as follows: 

• if X G C and x := t,x > d G CCond{C), P{x := t) > P{x > d); 

• if x,y G C and x := t,y := t — x G CCond{C), P{y := t — x) > P{x := f); 

Definition 12. Based on the sorting function o, its inverse function o~^ from 
Definition 4, we define operations 0 : Now x Now i— > Now and Q : Now x 
Now 1 -^ Now as follows, where Prop G 2^ is a proposition constraint subset, 
CCS,{ei,e 2 ,...,en} Q CCond{C): 

• Now® < Prop U CC^, o({ei, 62 , . . . , e„}) >= 

< Now.D U Prop U CCS,o{o~^{Now. E) U {ei,e 2 , ■■■ ,en}) >; 

• Now® < Prop U o({ei, 62 , . . . , e„}) >= 

< Now.D \ {Prop U CCS),o{o~^{Now.E)\{ei,e 2 , ■ ■ ■ ,en}) >■ 

Definition 13. For the clock x of a temporal operator, we define an assignment 
set AssSetx = {y := t, y := t — z \ y, z G AncSetx and z G AncSety}. 

5.2 Algorithm of Constructing Timed Automaton 

Definition 14. IfE is a set of MITL^Q iij formulas, the normal form NP{E) of 
E is computed with the following procedure. Let Pq = {< 0, < {4>},0 >,0 >}. 
As long as one of the rewrite rules in Table 2 ^can be applied to any of the terms 
in Now.D of Pn, then apply one to a term to obtain Pn+i. The normal form 
NP{T) is obtained from Pn when no more rules can be applied. 

Lemma 1. The equivalences between the basic MITL^q j^ formulas and their 
rewritten forms hold and the value of clocks is the time when the truth values of 
the sub-formulas within their domains are true until now. 

^ The clocks mentioned in this table is the clocks binding with its temporal operators 
defined in Definition 10. 
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Table 2. Rewrite rules 



(P = 


Conditions 


^ U {< CS, Now® < {0}, 0 >, Next >}reduces to 


true 




U { < CS, Now, Next >} 


false 




<p 


4>i V 4>2 




^ U {< CS, Now® < {0i}, 0 >, Next >, 
< CS, Now® < {02}, 0 >, Next >} 


<pi A (p2 




U {< CS, Now® < {01, 02}, 0 >, Next >} 






U {< CS[x 0], Now® < {4>iV\x.d\4>2} >}, 0 >, Next > 


01 Vjx.d] 02 




^ U {< CS, Now® < {01 , 02}, < X t >>, Next >, 

< CS, Now® < {02}, < X t >>, Next U {(piV[x,d](p 2 } >, 

< CS, Now® < {02}, < X t, X ~> d >>, Next >} 


0l'4o,dl.T02 




{< CS[y 0], Now® < {0i Vf^.dlT 02}, 0 >, Next >>} 






U {< CS, Now® < {01, 02}, < y t — X », Next >, 

< CS,NowQ < 0,o{AssSety) > © < {02}, 

< y \= t — X », Next U {0i^[y,d]3; 0} >, < CS, Now® 

< { 02 }, < y t — x,y > d », Next >} 


4>lU[0,d] 02 


02 ^ Now.D 


^ U {< CS, Now, Next >} 


02 ^ Now.D 


U {< CS, Now® <{02},<ai:— t>>. Next >, 
< CS, Now® < {01, 0 < t < d}, < X t >>, 

Next U {0it/fo.dl02} >} 


0 iG[o,d]3-02 


02 € Now.D 


^ U {< CS, Now, Next >} 


02 ^ Now.D 


U {< CS, Now® < {02}, < y t — X >>, Next >, 

< CS, Now® < 0, o(AssSety) > © < {0i, x < t < x ® d}, 

< y t — X >>, Next U {0i C/fo.dl 02} >} 



Definition 15. Let (j) be a basic MITL^q ^i^ formula, P be the set of propositions 
that occur in 4>. The tableau automaton is the finite-input timed automaton 
< S, So, C, Q, CC, OCC,Tran, Se > over 2^ , where 

• C is the set of all clocks computed by Definition 10; 

• S, So, Tran and Se can be computed by the procedure depicted in Fig. 3. 

• Q(s) = {(/> G 2^ I Vpg pp G Now.D ^ p € 4>,^p G Now.D ^ p ^ (j)} 

m CC{s) = {vG CCond{C) \ 77 G Now.D} 

• OCc{s) = o{t 7 G CCond{C) \ ry G Now.E} 

The algorithm presented above is correct and it can be stated by the following 
theorem. 

Theorem 1. Let (f) be an MLTL^o.d] formula and timed automaton be the 
corresponding tableau automaton, then for every timed state sequence t, A^ ac- 
cepts T iff T \= 4>. 

Case Study We consider the CSMA/CD protocol in section 4 again. While test- 
ing, we need presuppose the max testing time, such as 10^*^ /is. So above property 
can be rewritten as □[q_ioio] ((T ransl A Trons2) ^ O[o,m]coll) in MLTL[o,d]- Us- 
ing our method, we can get the tableau automaton for the above property, which 
consists of 18 states and 70 transitions. But the state and transition amount of 
the resulting automaton can be decreased to 12 and 35 ulteriorly, if we treat the 
sub-formula Transl A Trans2 from the example of CSMA/CD protocol as an 
atomic formula. And what we must modify is the component of rearrangement. 
For clarity we only draw the smaller automaton as Fig. 4, in which the round- 
corner rectangles denote states, the arrowed lines denote transitions. Every state 
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5„ ;= {{Now, Next) \< Now, Next >e NF{(p ) } ; 

^New ~ {{Now, Next) I {Now,Next) e 
S :=0,Tran ;=0; 

do 

{ 

Let ( Now, Next) 

■= \{{Now,Next)}-, 

S-.= S\J {{Now, Next)}-, 
for every {Now',Next')e NF{Next) do 
{ 

if {Now', Next ') = {0,0,0) then 
u {Now , Next ) ; 

Tran := Tran u {((A^ow,A^exf),(Wow Next '))} ; 
if {Now ', Next ’)i S then 5 ;= 5 u { {Now', Next ')} ; 



Fig. 3. Algorithm for constructing the states and transitions of the tableau automaton 



is divided into two parts, the upper of which denotes Now.D, and the lower of 
which denotes Now.E. In order to simplifying the representation, only the for- 
mulas in Now have been depicted. The initial extended states are represented 
by an arrow not originating form any state, and the finite states are denoted by 
a filled circle inside a slightly larger unfilled circle put in the lower part of the 
states. 

6 Conclusions and Future Work 

This paper presents a new method that can automatically generate run-time test 
oracles for DRTS. Test oracles can check whether a distributed real-time sys- 
tem’s traces are correct, based on real-time specifications written in M/TL[g 
formulas. If the test oracles can accept the timed event sequences, we can say 
that the runs are correct, i.e. the system runs correctly. Otherwise, if all cur- 
rent states can’t accept any subsequence timed events that violate state or time 
constraints, or the tail of some trace does not arrive at final state, we say the 
system has some errors or some real-time specifications errors exist. 

Compared with [9], whose computation is done at each end of cycles, our 
method does computation only if necessary (i.e. when system states change) so 
as to save precious computing time. Assertions inserted into the different parts 
of DRTS not only can obtain the inner events of DRTS, send out the values of 
states only when they change, but also can get the precise occurrence time of 
events. 
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I” 



x:=0 



::=0 



—(Tmnsl A Trans!) 



sc:=0 



X~t 



coll 



y^t-x 

x:=t 



—(Transl a Trans!) 
coll 



y=t—x 

X~t 



x<t<(X)+x 



y)=t-x 



4 y t t y 



x:=0 



—(Transl a Trans!) 



x:=t 

X>10“ • 



X := 0 



coll 



y=t—x 

x~t 

x>10“ 



—(Transl a Trans!) 

X</<60+X 



y:=t—x 






x<i<60+x 



x>10“ 
y.= t-x 






—(Transl a Trans!) 
coll 



y^t—x 

x:=t 

x>10“ 



—(Transl /\Trans!f\ 

x<i <60+x 



y^t-x 
x~t • 
x>10“ 



—(Transl a Trans!) 



X~t 






X<f <60+X 



y:=t—x 



Fig. 4. The Optimized tableau automata of D[q ]^Qio]((Transl ATrans2) ^ <>[o, 60 ]Coll) 



The ongoing works include: 

1. The method of automatic test oracles generating needs to be optimized in 
order to reduce the complexity of tableau automata and checking costs. This 
can be done by optimizing rewrite rules and timed automata. 

2. The real-time specifications used in this paper is the restrict version of MITL, 
MITL[o^d], that limits the ability of logic expression for properties of DRTS. 
For example, n[o.ioo](^[io, 20 ]T) can not be transformed into a test oracle. So 
how to extend the detection capability of test oracles is the main problem 
of future work. 

3. DRTS are running on networked environments, so we must consider the delay 
of network transmission while acquiring the system traces. When the events 
and their timestamps reach the test oracle, there must be a special part to 
arrange them so that the whole timed sequence is reordered by time and are 
0-fine. 

4. We must evaluate the computing costs of assertions inserted into the DRTS 
so as to assure that assertions will not influence the normal running of DRTS. 
The computing costs of assertions are decided by the amount and the data 
structures of assertions. And the next works must include it. 

5. Finally, more experiments in real environments are required. 
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Abstract. Eliciting, modeling, and analyzing the requirements are the main 
challenges to face up when you want to produce a formal specification for 
distributed systems. The distribution and the race conditions between events 
make it difficult to include all the possible scenario combinations and thus to 
get a complete specification. Most research about formal methods dealt with 
languages and neglected the process of how getting a formal specification. This 
paper describes a scenario-based process to synthesize a formal specification in 
the case of a distributed system. The requirements are represented by a set of 
use cases where each one is composed of a collection of distributed scenarios. 
The architectural assumptions about the communication between the objects of 
the distributed system imply some completions and reorganizations in the use 
cases. Then, the latter are composed into a global finite state machine (FSM) 
from which we derive a communicating FSM per object in the distributed 
system. 

Keywords: Use case. Scenario-based approach. Scenario composition. Formal 
specification. Distributed systems, FSM 



1 Introduction 

The computer science community agrees that the requirement elicitation and analysis 
is a crucial step in the development process. Nevertheless, most research about formal 
methods dealt with languages and neglected the process of how getting a formal 
specification. Consequently, there is gap that makes difficult moving from 
requirements towards a formal specification. Developers avoid this phase by passing 
directly from informal requirements to implementation. Unspecified reception, 
service denial, and deadlock are common bugs that may have uncontrolled 
consequences in the case of distributed systems. Detecting such bugs during the 
validation stage becomes difficult, reducing thus the reliability of the system and 
increasing the development costs. 

Scenario approaches have been emerged to fill the gap and facilitate the 
construction of a formal specification by promoting a “Divide and Conquer” strategy. 
A distributed scenario is a sequence of actions representing an execution trace 
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describing a partial behavior, and providing a system level functionality. The actions 
represent concurrent interactions between different system objects. The different 
scenarios have to be composed in order to provide a formal specification of the 
system. 

The requirements are widely represented by use cases where each one depicts a 
collection of scenarios. A scenario can be described by a message sequence chart 
(MSC), which emphasizes the interactions among objects. Our objective is to 
synthesize finite state machines (FSMs) from a set of use cases. Constracting 
communicating FSMs from MSCs is a very hard problem because MSCs may 
represent incomplete and inconsistent requirements. Combinatorial complexity makes 
it difficult to express MSCs for all of the possible scenario combination in the system 
behavior. Furthermore, systems may have many infinite traces, which cannot be 
easily captured by having only the MSC model. As a result, during the synthesis of 
FSMs, the analyst uses ad hoc methods based on his creativity and his expertness to 
fdl the gaps. 

MSCs and FSMs share some information, but emphasize two different views of the 
system behavior. First, MSCs represent the specification that the system should 
respect while FSMs are a model of the specification. Second, an MSC describes a 
story in which only some objects participate. Flence, it provides an inter-object view 
which makes it suitable for test and validation activities, but not for the 
implementation. In contrast, an FSM shows an intra-objects view where all the stories 
are about the same object [7] and may reflect their implementation. 

Assuming that the system is composed of a set of objects, we aim at automating the 
synthesis of FSMs from use cases. We propose a two-phase method. The first phase 
consists of generating MSCs from use cases for completing them with missing 
scenarios. The intended communicating FSMs should allow infinite runs but use cases 
describe only finite traces about the behavior. Therefore, the second phase consists of 
enriching the use cases with some information that captures loops in the behavior and 
allows a system state characterization used for the automatic synthesis of a 
communicating FSM per object. 

The paper is structured as follows: in Section 2, we give an overview of the 
notation we are using. Section 3 presents the formalization of use cases and scenarios 
using the tree presentation as well as the derivation of their MSCs. In Section 4 and 5 
respectively, we describe the approach we are proposing for decorating use cases and 
synthesizing the communicating FSMs. Discussions on some related work are given 
in Section 6. Finally, Section 7 closes the paper with conclusions and future work. 



2 Preliminaries, Definitions and Formal Semantics 

Let {Oi, 02,-., 0„} be the set of objects in the targeted distributed system, Env its 
environment, and^o ~ (So,Soimt,To} the FSM of object OieQ. Sg. is the set of states 
of Oi, Soinit is the set of initial states of and Tg. cr SgXZg^xSg^ is the set of 
transitions where £g is set of labels in the form (OiOj.m) or (Oj.Oi.m). The FSM has a 
powerful capability of abstraction needed during first stages of the development 
process. 
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In this work, the FSMs of objects are assumed to be communicating FSMs 
according to the semantics of input/output automata defined in [12], Each FSM object 
is autonomous and can communicate with other FSMs by means of message 
exchange. When an FSM object sends a message to another FSM, the latter is 
assumed to be ready to receive this message; otherwise there is an unspecified 
reception fault. The communication between FSMs is modeled by their parallel 
composition FSM denoted by ]lAo,=(S,Sinit,T). It is defined as the coimected 
components of the composition FSM of Aoj,Ao^,... and Aq , which contains a state 
from Sinit, where S=SiXS 2 X...xSn, and Sinit=SojinitXSojinitX---xSo_jinit- TcSxZxS is the 
set of transitions of HAo. defined by the following rules: 

- Rule 1: (Si,a,Si')e Tq, and (a^(0,0i.m) or a^(0i,0.m)) and O e {Oi, Env} 

implies ((si,..,Si.i,Si,Si+i,..,Sn),a, (si,..,Si.i,s’, Si+i,..,s^) e T 

- Rule 2: to O, ,0, eQ and i<j 

(s,a.sOe To, and (Sj, a,Sj)eToj and (a^(Oj,Oj.m) or a^(Oi,Oj.m)) implies 
((si,..,Si,..,Sj, ..,sj,a, (s I, e T 

Rule 1 treats internal actions or communication with the environment while Rule2 
treats communication among two different objects 0,and Oj. 

Message sequence charts (MSCs) [9] are a commonly used visual representation of 
scenarios expressing the interactions among objects, components or processes. An 
MSC focuses on message exchange and shows a partial order of events. A message 
represents an interaction between two objects, a sender and a receiver. MSCs may 
display an order of events which is not always the only case supported by the 
implementation of MSCs. The formalization of MSCs allows the definition of the real 
partial order according to particular architectural communication assumptions. The 
formalization of MSC was traded by many reseachers [3,4], and we propose a similar 
approach. 

We formalize an MSC as a structure (I, SE, RE, r, L, p, <d , <m) where 

- I czi2u{Env} is a set of objects 

- SE is the set of sending events and RE the set of receiving events. We denote by 
SEo (respectively REq) the set of sending events (respectively the set of 
receiving events) in object O 

- r : SE —^RE maps a sending event to its receiving event, r is a bijection. 

- Lis a set of labels of the messages in the MSC 

- p : SEuRE—^ I maps a sending event or receiving event to an object from 1 

- <D= Uoei<o where <o cz SEqUREq x SEqUREq is a total order between the 

local events in object O according to the visual order as displayed in the MSC. 

~ <m ^ {(s, r(s)) I s eSE} is an ordering relation which means that a message 
cannot be received before it is sent. 

The previous definition is very general and does not include any assumption about 
the communication architecture in the system. As the behavior described by MSCs 
will be translated into a set of communicating FSMs, their respective semantics 
should be compatible. Since the communication between FSMs, as defined in this 
paper, has no buffering facility, we assume that the FIFO order is preserved when an 
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object receives two or more messages from the same object. Thus, the events should 
fulfill the partial ordering relation <fifo ^ {(f(s),r'(s')) \ (s,s’) e<o and p(s)^p(s)and 
p(r(s))^p(r(s)) and seSE and s'eSE }. Furthermore, FSMs are modeling autonomous 
objects. Consequently, an object has the control over its sending events. Flence, its 
scheduling of sending events is granted according to the visual order <q. We also 
grant the local visual order between a receiving event and the next sending events in 
an object. Those facts are expressed by the following control ordering relation: <c 
={(e,s) I e e SEuRE, s eSE and (e,s) e<o and Oel}. Finally, the interpretation of an 
MSC is given by the partial order relation < defined as the transitive closure of the 
combination of the three partial ordering <c, <m and <fifo: 

< = (<(;; U U <FIFo)* 

3 Formalization of Use Cases and Scenarios 

A use case is used to describe a distributed functionality of the system as seen by 
actors (external users). The analyst usually builds use case diagrams, which 
emphasize the relationships between use cases. Then, she or he provides a textual 
description of the possible scenarios of each use case. This informal description is 
hard to be used in automatic processing of scenarios. Consequently, we conceived a 
formal model, which describes a use case by a tree of actions. The analyst constructs 
the tree of a use case by using either a depth-first or a breadth-first strategy in order to 
get a complete description according to the current requirements. As the use case tree 
paths are the scenarios of running the use case, the depth-first strategy is more 
convenient from a user point of view. Flowever, the breath-first strategy is suitable to 
check that all of the possible scenarios have already been included in the use case tree 
since after each action all the possible afterward actions are checked. Actions (also 
called messages) are labels like (Oi,Oj.m) where O, and Oj are objects of the system. 
(Oi,Oj.m) means that message m is sent from O, to Oj. 

We will be using a basic telephone system to illustrate our work. Fig. 1 shows use 
case “Make a call” that describes the behavior of the system when a user A calls a 
user B. We will assume that Q for the telephone system is composed of the following 
objects: A, B and a switch S. Let's now present the formal definition of our use case 
model: 

Definition: A use case Wis a tree r=<Id,M,Mstart,Parent> where: 

- r.Id is the id of the use case, 

- r.Mcz (£2u{Env})x(£2u{Env}.Label) is the set of messages in the form 
(O.O’.m), 

- r.Ms,art<^r.M is the set of starting messages, 

- r.Parent is a function that associates to a message the index of its parent 
message. Function r.Parent is not defined for starting messages. 

The scenarios of a use case are complete paths starting from a start message and 
ending at one of the free leaves. From each use case scenario, an MSC is generated. 
The generation of MSCs is only based on the syntax of messages and their order in 
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the use case tree paths. The syntax of message label identifies the sender and the 
receiver objects. The use case tree of Fig. 1 contains three scenarios. We have drawn 
in Fig. 2 the MSCs generated from use case “Make a call”. 

MSCs are less intuitive than expected. Their visual order does not always represent 
all their possible executions as only a partial order of events is garanted according to a 
particular adopted semantics of MSCs. For this reason, researchers defined the notion 
of MSC linearizations [2] [15] to represent the possible executions of an MSC. 

In this work, the linearization of an MSC is a total order relation which is 
consistent with its partial order relation <. If an MSC has many linearizations, some 
of them may not be included in the use case tree since they may have escaped to the 
user requirements. Thus, the partial order of an MSC helps the analyst to detect and 
possibly complete the use case tree by adding those absent linearizations after the user 
validation as illustrated in Fig. 3. If the user refuted one of the linearizations of an 
MSC, it means that the use case tree should be modified so that its generated MSCs 
accept no more the refuted linearization. 




Fig. 1. The tree of use case “Make a call” 
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(03,02.m4) 




Fig. 3. Use case completion by adding absent linearizations; step (a): the MSC generation; 
step (b): adding a missing linearization to the use case 
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Fig. 4. Use case reorganization process: (a) Original use case tree, (b) Its generated MSC. 
(c) The proposed reorganized use case tree 



The user may sometimes be eonfused and does not realize that his use ease is 
eomposed of a eombination of independent traees. To formally define what 
independent traees means, let first define the set of minimum event Min of an MSC: 

Min^{eeSE\ Ve'eSEuRE . (e',e)g<} 

Min denotes the set of sending events where eaeh one may initiate a sequence of 
events, called independent trace. If Min is not a singleton, the partial order of an MSC 
may be used to find out independent traces. 

If the generated MSCs of a use case include many independent traces as shown in 
Fig.4 (b), the computation of the set Min allows a reorganization of the use case so 
that the causality relationship between the independent traces becomes explicit as 
illustrated in Fig.4 (c). However, if the user refuted the proposed reorganization of the 
use case, it may mean that there are parts of the use case that are missing and should 
establish the causality relationship he intended. 



4 Decorating Use Cases with a State Characterization 

The compatibility of use cases and their generated MSCs is reached when both of 
them accept the same scenarios. Our goal is to synthesize FSMs from use cases. As 
known, it is possible to generate FSMs from a set of traces. However, the behavior 
provided by use cases is partial since they don't include infinite traces or repetitive 
behaviors. High-level MSCs (HMSCs) are MSC-graphs where each node is an MSC 
[9]. They provide a mean to define how MSCs can be combined and they can express 
infinite traces of the system behavior. However, HMSCs specify an explicit 
combination of MSCs, available only in an advanced stage during system requirement 
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analysis. Therefore, we adopted an alternative strategy that eonsists of decorating use 
cases with a state characterization. The latter allows not only capturing infinite traces, 
but also recognizing shared states in different scenarios and thus determining their 
relationships as well as the relationship between their respective use cases. 

Decorating use cases gives the analysts the opportunity to add their interpretations 
regarding the state of the system when an action is performed. It consists of 
specifying for each message (action) of the use case partial pre and partial post 
conditions expressed by state variable constraints. Those conditions are qualified to 
be partial because they have to be completed by the fact that this action takes place 
before and after specific actions in the use case. State variables are defined by the 
analyst and their values represent the state of the system. As the latter is composed of 
a set of objects, the state of the system is also composed of the states of its objects. 
Subsequently, the state of an object can be derived from the global system state. 

In practice, state variables have symbolic names. However, we will use here a 
vector-based notation because it is more convenient to present the general case. The 
state of the system is represented by a state vector V^(vi,V 2 ,..,Vk) where v, is the value 
of state variable V[i] and k is the number of state variables. We write dom(V[i]) the 
finite domain of possible values of state variable V[i] . A state variable may also be 
instantiated with a special value, denoted by nil, which means that its current value is 
not fixed yet in that state. Hence, the space of state vectors is the product set 
DOM^(dom(V[l])u{nil})x(dom(V[2])u(nil})x... x(dom(V[k])u{nil}). 



Table 1. Decoration of use case “Make a calF. The state vector is composed of the values of 
four variables SigA, StaA, SigB and StaB. SigA describes signals of terminal A, and 
Dom(SigA)={N,DT,D,BT,Tj where N means no signal, DT dial tone signal, D dialing signal, 
BT busy tone signal and T talking signal. StaA describes the status of terminal A and 
Dom(StaA)={I,B} where B stands for busy and I for idle. Variables SigB and StaB describe 
respectively the signals and the status of terminal B. Dom(SigB)={N,BT,R,Tj where R stands 
for ring signal and the other values are the same like in Dom(SigA). Dom(StaB)={B,I}. We have 
also decided that EP is set to False for all messages in this use case tree 



Index 

(msg) 


Parent 

(msg) 


msg 


ppre(msg) 


ppost(msg) 


0 


- 


(A,S.PickUp) 


SigA =N and StaA =/ and 
SigB=nil and StaB=nil 


StaA’=B 


1 


0 


(S,A.DialTone) 


True 


SigA’=DT 


2 


1 


(A.S.DialB) 


True 


SigA’=D 


3 


2 


(SA-BusyTone) 


StaB=B 


SigA'=BT 


4 


3 


(A.S.HangUp) 


True 


SigA ’=N and StaA —I and 
SigB ’=nil and StaB '=nil 


5 


2 


(S.B.Ring) 


SigB=N and StaB=l 


SigB ’=R and StaB '=B 


6 


5 


(B.S.PickUp) 


True 


SigB’=T 


7 


6 


(S,A.Talk) 


True 


SigA ’=T 


8 


7 


(B.S.HangUp) 


True 


SigB ’=nil and StaB '=nil 


9 


8 


(SA-BiisyTone) 


True 


SigA'=BT 


10 


9 


(A.S.HangUp) 


True 


SigA ’=N and StaA ’=/ 


II 


7 


(A.S.HangUp) 


True 


SigA ’=N and StaA ’=/ 


12 


11 


(S,B.BiLsyTone) 


True 


SigB'=BT 


13 


12 


(B.S.HangUp) 


True 


SigB ’=nil and StaB '=nil 
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The decoration of a use case consists of specifying for each message three 
declarative attributes: a partial pre-condition, a partial post-condition, and an 
extension point. The partial pre and post-conditions of a message m are denoted by 
ppre(m) and ppost(m) respectively. The state variables must fulfill the constraints 
ppre(m) before sending message m and ppost(m) after its reception, ppre(m) is a 
conjunction of elementary constraints in the form {V[i]=v) where v is a constant of 
dom(V[i]). In contrast, ppost(m) constraints the relation between the vector state V 
before m and V the state after m. Thus, ppost(m) is a conjunction where elementary 
constraints are either (VJiJ^v), V'[i]^ V[i] op v), or (V'[iJ^ V[I]), and where op is 
an operator defined on the variables domain. 

By default, a non-instantiated variable will be initially set to nil. Afterwards, we 
adopt the STRIPS [5] strategy to deal with the frame problem and assume all that is 
not explicitly changed by an action remains unchanged. Furthermore, whenever we 
have a conjunction' in the form (V[i]=v and V[i]=nil) the latter is unified to 
(V[i]=v). This unification is needed later on in the computation of the canonical form 
of the use case. 

Finally, the third element of the decoration is the extension point. Since the analyst 
has to compose many use cases to construct the overall system behavior model, we 
associate to each message m a predicate denoted by EP(m) which stands for extension 
point, similar to use case extension point in UML [16]. EP provides to the analyst a 
mean by which she or he can control how parts of FSMs coming from different use 
cases can be connected. By default, for a message m that it is not a leaf, the value of 
EP(m) is “False" in order to prevent overlapping use case traces. In contrast, the 
analyst decides which value should be assigned to predicate EP for other messages. If 
the EP is "True", it means that the execution of the system continues in the current 
use case. Otherwise, it indicates that the system may exit the current use case and 
continues its execution in another one. In this case, it represents the concatenation of 
use case traces. The decoration use case “Make a call” is presented in Table 1 . 



5 Synthesis of Communicating FSMs 

Synthesizing communicating FSMs from decorated use case trees takes three steps: 
(1) transforming use cases into a canonical form, (2) synthesizing a global finite state 
machine (GFSM) from the canonical form of all use cases, (3) deriving from the 
GFSM a communicating FSM for each object in the system. 

Step (1): Canonical Representation of Use Case Trees 

The requirements of a system are composed of a number of use cases. Their overall 
behavior can be implemented by synthesizing communicating FSMs. For this end, we 
need a representation of use cases that not only captures their behavior, but also 
facilitates their merge into a global state model. We adopt thus a canonical 
representation of use cases in the form of a flat set of m-rules. An m-rule is an atomic 



1 



This conjunction differs from the ordinary logical AND since it provides a rewriting rule 
when a formula contains “V[i]=nil”. 
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message rule, whieh deseribes the states of the system before a message is sent and 
after it is reeeived. Formally, an m-mle is a 3-tuple mr=(LHS,RHS,lab) where mr.LHS 
is the left hand side of the rule and represents the pre-eondition part, mr.RHS is the 
right hand side whieh is the post-eondition part, and mr.lab is the message 
synehronization label of the m-mle. We reeall that mr.lab is in the form (Oi.Oj.m). 

In order to tag the states and the transitions in the targeted FSMs with the use ease 
id from whieh they eome, we extend the set of state variables with a new variable 
ealled uc. Tagging the FSMs is not only used for traeeability reasons, but also to 
implement information given by predieate EP related to the extension points of a use 
ease. From now and on, the state veetor is eomposed of all state variable values and 
the value of the reeently introdueed variable uc. The domain of variable uc is the set 
of use ease ids plus a speeial value denoted by nolle that tags the state veetors that 
may be shared by a eertain number of use eases. 



Input 


<r,pre,post, EP> where F=<Id, M, M. . ,Parent> 


is a decorated tree with ppre, ppost, and EP 


Output 




(1) R:=0; 


R. :=0 


(2) For each msg g F.M do 


(3) 


mr . lab : =msg 


(4) 


If msgG then 


(5) 


mr.LHS:= ( ppre(msg) and uc= noUc) 


(6) 


Else mr . LHS : = (ppre (msg) and 
ppost (parent (msg) 

and uc=r. Id ) 


(7) 


For each msg'G F.M | msg=parent (msg ' ) do 


(8) 


If EP (msg) =False then 


(9) 


mr.RHS := ( ppost (msg) and ppre (msg') 
and uc=r.Id ) 


(10) 


Else mr.RHS := (ppost (msg) and ppre (msg') 
and uc=noUc) 


(11) 


R:=Ru{mr} /*mr is added to R unless 
mrg R*/ 


(12) 


If msg G r.M. then R. . •=R. .,u(mr} 


(13) 

(14) Done 


Done 



Fig. 5. Computing the canonical form of a use case 



We define the eanonieal representation of a use ease as a pair of m-mle sets 
denoted by <R,R,tart> and derived from the use ease. The algorithm at Fig. 5 deseribes 
how <R,Rstart> is eomputed from a use ease. As shown in lines (8) to (11) in this 
algorithm, the same message may be duplieated into several m-mles sueh that eaeh 
one would have an RHS that eonforms the pre-eondition in one of its next messages in 
the use ease. Eaeh extraeted m-mle is tagged with the use ease id by eonstraining its 
LHS and LRS with either the eonstraint (uc^F.Id) or the eonstraint (uc=noUc) 
aeeording to the value of the predieate EP in its message. Flenee, state veetors 
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satisfying (uc=rid) are specific to use case F. In contrast, state vectors where we 
have (uc=noUc) shared by the use cases where the other state vector components 
coincide. Consequently, use cases having such state vectors may have their respective 
FSMs connected to each other by those shared state vectors. A conflict is reported to 
the designer whenever there is any m-mle from a use case that has false in either its 
LHS or RHS constraints. 



Step (2): Synthesizing a Global Finite State Machine 
from Decorated Use Case Trees 

The global finite state machine (GFSM) is an FSM constmcted from all use cases. 
Assuming that we have a communicating FSM for each object, the GFSM should 
represent the FSM of their parallel composition. The GFSM accepts at least all the 
complete paths of the use case trees. 

In practice, we directly derive the GFSM of a use case from its canonical 
representation. Let <S,Si„u,T> be the GFSM of a use case for which the canonical 
representation is <R,Ri„u>. Let [r.LHS] be the set of state vectors which verify the 
constraint r.LHS and [r.RHS] the set of pairs of state vectors that verify the constraint 
r.RHS. We define the GFSM <S,Si„u,T> by the following: 

T = {{V, l,V’)\3re R.Ve [r.LHS] 

and (V,V')e [r.RHS]and I = r.lab} 

S =^e DOM \ {V,_,_)eT or {_,_,V)eT} 



S is the set of states of the GFSM and composed of state vectors, which satisfy 
either the LHS or the RHS of an m-mle. T is the set of transitions. Each one comes 
from an m-rale. We point out that the GFSM can be non deterministic. The GFSM of 
use case “Make a call” is drawn in Fig. 6, and its state vectors are described in 
Table 2. 

We have so far treated the constraction of the GFSM of one use case. The 
generalization to the case of two or more use cases consists of synthesizing the GFSM 
derived from the union of those use cases canonical representation. We define the 
union of two canonical representations <R,Ri„u> and <R',Ri„u'> as <RuR' 
>Rmil^RmU 



Table 2. State vectors of GFSM of use case “Make a call“ 
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DT 
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BT 


D 


D 


D 


T 


T 


N 
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StaA 
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B 


B 


B 


B 


B 
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I 


I 


SigB 
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nil 


nil 


nil 
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N 


R 


T 


T 


Nil 


T 


BT 


StatB 
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nil 
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B 
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B 


B 


Nil 


B 


B 


uc 


nolle 
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I 
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1 
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I 
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(B.S! IcngUp) 

Glj (A,S.%angUp) 

91 



(S.BBusyTone) 



(A.S.Pickup) 

2) 

(S.A.Dialtone) 



\S.A.BusyTone ) ' 



(A.S.DMAB) 



(A.p.HangUp) j 

(S.A.BusyTope) 

(B.S.HangUp) ' .S.Di^AB) 





(B.S.Pickup) 

Fig. 6. GFSM of use case “Make a call” 



(B,S.HangVp) 

(A.SMongVp) 

(S.B. tsyTonef 





(S.A.Dialtpm) 



(A.k.HangUp) 

I ^S.A.BusvTofje) 



^S.A./a 



* 

jff.A.ilun'Tone/^^ 

\ (A.S.pialAB) 



(S,B.0ng) 



(B.S.Pickup) 

Fig. 7. DGFSM of use case “Make a call” 



Inputs : 

- DGFSM <S,S.^.^,T>, { S.^.^ is a singleton } 

- O an object in Q 

Output ; 

-<So,SQi„.^, Tq>, the FSM of object 0 

T • =0 ■ S -=0- S • =0 
/*Clustering states */ 

For each (V, (O. , 0. .m) , V' ) in T do 
If (O.s^O and O.^^O) then 
Sj,:=Cluster (V,V' ,SJ 
Else 

Sj,:=Cluster (V,V,SJ 
Sj,:=Cluster (V' ,V' ,SJ 
fi 

done 

Tq : = { (C, msg, C' ) I (V,msg,V') g T and Vg C 

and V'gC' } 

Soi„it:= {C I CGS„ and 3 Vg . VgC} 

Return (S„, So, 

Where Cluster (V,V' , CS) : 

If (3 CE G CS such that Vg CE ) then C:=CE 
Else C:= 0 

If (3 CE' G CS' such that V'g CE' ) then C' :=CE' 
Else C:= 0 

Return (CS\{C,C' }u{CUC' u{V, V' }}) 



Fig. 8. Construction of the FSM of an Object 
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Fig. 9. The FSM of Terminal A (left side) and the FSM of the Temiinal B (right side) 



Step (3): Deriving Communicating FSM for Each Object 

The derivation of an FSM for an objeet eonsists of clustering some states and 
removing some transitions from the deterministic FSM (DGFSM) which correspond 
to the GSFM of all use cases. The DGFSM can be obtained from the GFSM by using 
the algorithm given in [1]. We assume that the state of an object is supposed 
unchanged if no action occurs in that object according to the GFSM. Consequently, 
the FSM states of an object O are obtained by clustering into the same state all the 
states of the GFSM that are connected with a transition in which object O does not 
participate. The transitions of the FSM of an object O are only those transitions of the 
GFSM representing messages or actions in which the object O participates. This 
algorithm is presented in Fig. 8. The FSM of an object implements all the parts of use 
cases in which that object participates. Consequently, the FSM of an object 
implements the object behavior. 

We have constructed from the DGFSM (c.f. Fig. 7) the FSMs of objects ^"Terminal 
A^\ “Terminal B”, and “SwitcK\ The FSM of object “Switch S’" resulting from that 
algorithm is exactly the entire FSM in Fig. 7. Flowever, The FSMs of objects 
“Terminal A” and “Terminal B” respectively are drawn in Fig. 9. 

The FSM of an object represents its behavior as described by the input decorated 
use cases and it is not error free. The FSMs can be inspected for some patterns and 
may reflect some errors. For example, the states in the FSM of an object should not 
have any self-loop transition. The latter shows that the object accomplishes an action, 
but its state does not change, a contradictory fact to use case decoration assumptions. 
With the use case id in the state vector we can trace back exactly where the analyst 
should intervene to correct the anomaly. 



6 Related Work and Discussion 

Researchers have intensively investigated the transformation of scenarios into 
transition-based system model during the last ten years. To deal with these topics, the 
key idea is how to identify states at the scenario level such that those states can be 
recognized in different scenarios and then integrated in the target global model. There 
are two kinds of state characterization: trace-based [8,10,11,13], and variable (or 
label) state-based characterization [17,18,19]. In this paper we adopted the second 
approach to identify the states of the system. 
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Harel et al. [8] tackled the problem of synthesizing statecharts from LSCs (Live 
sequence charts), an extended form of MSCs which support liveness by specifying 
universal and existential scenarios. Their approach consists of synthesizing global 
automaton with accepting states from LSCs using trace-based state characterization. 
The global automaton can be decomposed into an automaton per object. The latter 
constitutes the overall statechart. Since we focus on first stages of requirement 
analysis, we believe that MSCs are easier to use with decoration and to validate. 
Moreover, practicing decoration is not compatible with LSCs because it may threaten 
their notion of universal scenarios. 

The closest approaches, in terms of state characterization, to our are [17,18,20]. In 
the first one. Whittle et al. [20] captured domain information by specifying for each 
message type a pre and a post-condition once for all. Contrarily to what we propose, 
sequence diagrams SDs (a variant of MSCs) are transformed into an FSM per object 
and per SD using a state-variable unification and propagation procedure. However, 
the state unification definition does not consider the causality relation between the 
unified states. The FSMs of an object are then merged into a single FSM based on 
defined state similarities. The authors introduced hierarchy into FSMs based on state 
variable ordering, class diagrams and generalization of transitions. Moreover, 
message passing is assumed to be hand shacking. Thus, the SDs would have only a 
single linearization. 

The work presented in [17,18] shows techniques for synthesizing timed automata 
from scenarios with respect to time constraints. Timed automata allow the description 
of the behavior of real time reactive systems. The scenarios can be seen as an 
enriched form of MSCs. The state characterization is very similar to the one we have 
presented in this paper. In contrast, the state vectors as defined in this paper are 
global, so they capture simultaneously the states of all objects. Giese [6] presented 
too an approach towards the synthesis of parametric timed automata from scenarios. 
Un-timed scenario are first derived according to existing approach like the one of 
Uchitel et al. [19], then the timing constraints are added in an incremental manner as 
time boundaries. The approach detects all the timing conflicts that can occur when 
integrating different scenarios, and hence can be adjusted. Contrarily to the approach 
in [18], Giese is synthesizing more than one automaton in the same time. 

In most cases, the composition of scenarios ends up with the creation of 
unexpected implied scenarios. The latter could stress incompleteness in the 
specification so it is useful to add them to the use case, or they express undesired 
behaviors that have to be removed from the targeted model. Many researchers have 
tackled the problem of detection and elimination of implied scenarios [2,13,14,19]. 
Alur et al. [2] have developed an algorithm to transform a set of MSCs into 
communicating state machines. Their approach has the potential of detecting all the 
implied scenarios from a set of MSCs. However, they consider only the case of finite 
traces. Uchitel et al [19] added the HMSCs to the specification so that they introduce 
the infinite execution aspects. Their approach consists of first constructing the labeled 
transition system of each object after what they compose them to obtain the overall 
implementation of the system. Our approach, however, uses the concept of decoration 
to detect loops and hence introducing the infinite behavior aspect in the specification. 

An important issue is whether or not all implied scenario have to be eliminated. 
Some researchers make the choice to produce a specification that is the closest 
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possible to the original use eases. Thus, they eonduet their approaehes in such a way 
they detect implied scenarios and eliminate them [14,19]. Such decision has the 
advantage to be automatic. However, others [13] make the choice to return back to the 
user to accept or refute a detected implied behavior. The advantage here is the 
enhancement done to the original use case. We opted for the second alternative 
because we believe it has the potential to complete the system behavior. 

Our approach differs substantially from the earlier presented work by the following 
points. We introduced an intermediate level of granularity, which is the level of use 
cases. Use cases themselves include a finer level of granularity represented by 
scenarios. 

Furthermore, from the described behavior in the user case and using its generated 
MSCs, we detect the other unexpected scenarios due to race conditions in a 
distributed system. Those implied scenarios are detected by enumerating all the 
linearizations of the MSCs the use case does not accept. This procedure offers the 
opportunity to remove in an early stage the undesired behaviors and allows the user to 
complete his current use case. In addition, the decoration of a use case by state 
characterization is easier than the decoration of an isolated MSC because a use case 
provides a broader view that shows the relationships between its scenarios. Moreover, 
a message which belongs to several scenarios will be decorated only once in the use 
case. 

Our approach distinguishes between two classes of implied scenarios: the intra-use 
case implied scenarios and the inter-use case implied scenarios. We define the former 
as a trace that the GFSM of a use case accepts but not its tree. This trace is the direct 
result of the use case decoration for which the role is to make possible such traces. 
The use case decoration configures the set of accepted traces to fit the user 
expectations. An inter-use-case implied scenario could be defined as a trace, which 
cannot be completed to correspond to a concatenation of complete path from different 
use cases. By construction, we can claim that there are no such implied scenarios in 
the GFSM of the system because of tagging private states in the use cases with their 
respective ids. 



7 Conclusion 

We have so far presented a method for constructing a communicating FSM from use 
cases expressed in the form of trees. MSCs are generated from use case trees and 
validated by users. The validation process consists of inviting the user to decide about 
accepting or not each one of the MSC linearizations missing in the use cases. 
Moreover, the user can also be prompted how to reorganize a use case in order to 
move forward a more stmctured specification. At the end of this stage, the original 
use cases may be modified to reflect more a desired and realizable system behavior. 
Use cases are then decorated for detecting repetitive behaviors and constructing their 
GFSM. Afterward, the latter is decomposed to derive a communicating FSM for each 
object. 

The decoration of the use case trees seems difficult at first time, but with practice, 
analysts will develop skills to perform appropriate declarative decoration. Moreover, 
practicing decoration is very helpful for a well understanding of the requirements. 
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especially in the case of distributed systems. Besides, even not explicitly shown, our 
approach preserves the traceability between use cases and the FSMs of objects. 
Hence, for any element (either a state or a transition) in the FSMs, we can retrieve the 
use case it is related to. So, when errors are detected in the FSM level, the analyst will 
be able to trace them back and correct them in the use case level. Our approach would 
be more efficient when implemented as a computer aided design tool with a graphical 
interface, which is under development. 
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Abstract. Controllability and observability problems may manifest 
themselves during the application of a test or checking sequence in a test 
architecture where there are multiple remote testers. These problems of- 
ten require the use of external coordination message exchanges among 
testers during testing. It is desired to construct a test or checking se- 
quence from the specification of the system under test such that it will 
be free from these problems without requiring the use of external coor- 
dination messages. This paper investigates conditions that allow us to 
construct such a test or checking sequence. For specifications satisfying 
these conditions, procedures for constructing subsequences that elimi- 
nate the need for using external coordination messages are given. 



1 Introduction 

Testing an implementation of a system is often carried out by constructing an 
input sequence from the specification of the system, applying the input sequence 
in a test architecture, and analyzing the resulting output sequence to determine 
whether the implementation conforms to the specification on this input sequence. 
In distributed testing, a distributed test arehiteeture is used where a tester is 
placed at each port of the system under test (SUT) N and an input sequence 
constructed from the specification M modeling the externally observable be- 
haviour of N is applied. Such an input sequence is called a test sequence [11, 12] 
or checking sequence [4, 6] and is constructed from M to determine whether N 
is a correct or faulty implementation of M . 

During the application of a test or checking sequence to V in a distributed 
test architecture, the existence of multiple testers brings out the possibility of 
coordination problems among remote testers known as controllability and ob- 
servability problems. These problems occur if a tester cannot determine either 
when to apply a particular input to an SUT, or whether a particular output 
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from an SUT is generated in response to a specific input, respectively. Without 
loss of generality, let us consider a distributed architecture where there are two 
testers called, for instance, the lower tester (L) and the upper tester {U). In this 
architecture, U and L are two remote testers that are required to coordinate the 
application of a test or checking sequence. The controllability (synchronization) 
problem manifests itself when L (or U) is expected to send an input to N after N 
responds to an input from U (or L) with an output to U (or L), but L (or U) 
is unable to determine whether N sent that output. It is therefore important 
to construct a synchronizable test or checking sequence that causes no control- 
lability problems during its application in the distributed test architecture. For 
some specifications, an input sequence can be constructed such that no two 
consecutive inputs will cause a controllability problem, and hence the coordina- 
tion among testers is achieved indirectly through their interactions with N [12]. 
However, for some other specifications, there may not exist an input sequence in 
which the testers can coordinate solely via their interactions with N [1]. In this 
case it is necessary for testers to communicate directly by exchanging external 
coordination messages among themselves over a dedicated channel during the 
application of the input sequence [2] . 

During the application of even a synchronizable input sequence in a dis- 
tributed test architecture, the observability problem manifests itself when L 
(or U) is expected to receive an output from N in response to either the previ- 
ous input or the current input and because L (or U) is not the one to send the 
current input, L (or U) is unable to determine when to start and stop waiting. 
Such observability problems hamper the detectability of output shift faults in N 
i.e., an output associated with the current input is generated by N in response to 
either the previous input or the next input. To ensure the detectability of poten- 
tial output shift faults in N the test or checking sequence needs to be augmented 
either by additional input subsequences selected from the specification M [10] or 
by external coordination message exchanges between testers [2] such that during 
the application of the input sequence testers can determine whether the output 
observed is received in response to the correct input as specified in M. Again, for 
some specifications, an input sequence can be constructed without using external 
coordination messages among testers such that no potential output shift faults 
will remain undetected, and hence the coordination among testers is achieved 
indirectly through their interactions with N. However, for some other specifi- 
cations, there may not exist an input sequence in which observability problems 
can be resolved without using direct external coordination message exchanges 
among testers. 

Both controllability problems and observability problems may be overcome 
through the use of external coordination messages. However, there is often a cost 
associated with the use of such messages. This cost includes the expense of im- 
plementing the infrastructure required in order to allow the messages to be 
sent and may also include a cost of a delay introduced by the sending of each 
message. It is thus desirable to construct a test or checking sequence from the 
specification of the system under test such that it will be free of controllability 
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and observability problems without requiring the use of external coordination 
message exchanges. Previous authors have investigated the problem of produc- 
ing a test or checking sequence that either has no controllability problems or no 
controllability and observability problems and that either uses no external coor- 
dination message exchanges or uses a minimum number of external coordination 
message exchanges (see, for example, [1, 3, 5, 7, 8, 9, 13, 14, 15, 16]). 

This paper investigates conditions that allow us to construct a test or check- 
ing sequence without encountering controllability and observability problems 
and without using external coordination messages among testers. The rest of 
the paper is organized as follows: Section 2 introduces the terminology. Sec- 
tion 3 gives a formal definition of the problem and identifies the conditions that 
the specification of the system under test is checked against. Section 4 presents 
new procedures for constructing subsequences that eliminate the need for using 
external coordination messages: for a transition t and port p we produce a sub- 
sequence that does not allow a fault in the output of t at p to be masked by an 
output shift fault. Section 5 gives the concluding remarks. 

2 Preliminaries 

2.1 FSM and Its Graphical Representation 

An n-port Finite State Machine M (simply called FSM M below) is defined as 
M = (S', /, O, S, A, So) where 

— S is a finite set of states of M ; 

— So € S is the initial state of M; 

— I = Ur=i where A is the input alphabet of port i, and A D I j =0 for 
i,j e [l,n], i yf j; 

— O = nr=i(^» {~})i where Oi is the output alphabet of port i, and — 

means null output; 

— (5 is the transition function that maps S x / to S, i.e., S : S x I S; 

~ A is the output function that maps S x I to O, i.e., A : S x / — *■ O. 

Note that each y € O is a vector of outputs, i.e., y =< oi, 02 ,...,o„ > 
where Oi € Oi U {—} for i € [l,nj. We will use * to denote any possible out- 
put, including — , at a port. We also use * to denote any possible input or any 
possible vector of outputs of a transition. In the following, p S [l,n] is a port, 
X € I is a general input, and G Ip is an input at specific port p. We use 
y[p, c] to denote the output vector y of a transition whose output at port p is c. 
Alternatively, we use y |p to denote the output at port pin y. 

A transition of an FSM M is a triple t = (si,S 2 ,x/y), where si,S 2 G S, 
X G I, and y G O such that <5(si,a;) = S 2 , A(si,x) = y. si and S 2 are called the 
starting state and the ending state of t respectively. The input/output pair x/y 
is called the label of the transition. A transition (si, S 2 , x/y) will also be denoted 

x/y 

>S2- 



as Si 
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A path p = t\ t2 ■ ■ ■ ifc (A: > 0) is a finite sequence of transitions such that 
for k>2, the ending state of ti is the starting state of ti+i for alH G [1, /c — 1]. 
When the ending state of the last transition of path pi is the starting state of 
the first transition of path p2, we use pi@p2 to denote the concatenation of paths 
Pi and p2- The Zo&eZ of a path (si, S 2 , (s 2 , S 3 , X 2 / 1 / 2 ) {sk,Sk+i,Xk/yk) 

{k > 1) is the sequence of input/output pairs xijyi X 2 / 2/2 Xk/yk which is 
called an input/output sequence. We will consider FSMs that are free from same- 
port-output-cycles and isolated-port- cycles. A same-port-output-cycle in an FSM 
is a path (si, S 2 , a^i/yi) (s 2 , S 3 , X 2 /J/ 2 ) ■ • • {sk, Sk+i,Xk/yk) {k > 2 ) such that si = 
Sk+i, Si yf Si+i for i G and there exists a port p with pi — and Xi ^ 

Ip for all i G An isolated-port-cycle in an FSM is a path {si, S2, xi/yi) 

(s2,S3,X2/y2) lsk,Sk-ki,Xk/yk) {k > 2) such that si = s^+i, Si yf s^+i for 
i G [1, fc], and there exists a port p with pi \p= — and Xi ^ Ip for all i G [1, A:]. 

We will use 2-port FSMs to show some examples. In a 2-port FSM, we will 
denote the ports U and L to stand for the upper interface and the lower interface 
of the FSM. We use u, ui, U 2 , ... to denote inputs at port U, and I, l\, I 2 , ... 
to denote the inputs at port L. The output vector y = ( 01 , 02 ) on the label 
of a transition of the 2-port FSM are pairs of output oi G Oi at port U and 
output 02 G O 2 at port L. 

2.2 Controllability (Synchronization) Problem 

Given an FSM M and an input/output sequence xijyi X 2 / 2/2 • ■ • Xk/pk of M, 
where Xi G I and yt G O, i G [l,fc], a controllability (synchronization) problem 
occurs when, in the labels Xi/pi and Xi+i(yi+i of any two consecutive transi- 
tions, 3p G [l,n] such that Xj+i G Ip, Xi ^ Ip, pi \p= — (i G [1,A: — 1]). Two 
consecutive transitions ti and ti+i whose labels are Xi/pi and Xi+i/pi+i, form 
a synchronizable pair of transitions if U+i can follow ti without causing a syn- 
chronization problem. Any (sub)sequence of transitions in which every pair of 
transitions is synchronizable is called a synchronizable transition (sub) sequence. 
An input/output sequence is said to be synchronizable if it is the label of a syn- 
chronizable transition sequence. 

2.3 Observability Problem 

Suppose we are given an FSM M and an input/output sequence xijyi X 2 /J /2 
. . . Xk/pk of M, where Xi G I and pi G O, i G [1, A:]. A 1-shift output fault in an 
implementation N oi M exists when, in the labels Xi/pi and aii+i/t/i+i of any 
two consecutive transitions, one of the following holds: 

1. There exists o G Op and p G [1, n] such that pi |p= o, pi+i \p= —, N produces 
output — at p in response to Xi after x\ . . .Xi-i, and N produces output o 
at p in response to Xi+i after xi . . .Xi. 

2. There exists o G Op and p G [1, n] such that pi \p= —, pi+i \p= o, N produces 
output o at p in response to Xi after x\ . . .Xi-i, and N produces output — 
at p in response to Xi+\ after x\ . . .Xi. 
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An instance of the observability problem manifests itself as a potentially 
undetectable 1 -shift output fault if there is a 1 -shift output fault related to o G Op 
in any two consecutive transitions whose labels are Xi/yi and Xj+i/j/i+i, such 
that Xi+i ^ Ip. In this case, we say that the tester at port p is involved in the 
shift, and would not be able to detect it. 

3 Problem Definition and Conditions 

3.1 Problem Definition 

Suppose that a specification of the system under test is given as an n-port FSM. 
Each potential undetectable 1 -shift output fault in the given FSM is related to 
a pair of transitions ti and t2 adjacent at a state of the FSM. Clearly, one can 
identify all potential undetectable 1 -shift output faults in the given FSM using 
the definition in Section 2 . 3 , and form a set of pairs of transitions where each 
pair of transitions ti and t2 is related to a potential undetectable shift of an 
output at a specific port p. Note that, if there exists a potential undetectable 
forward shift of output d at port p from transition ti to transition t2, then, this 
potential shift may be realized in an implementation, by a missing output d 
at port p in 1 1 and an extra output d at port p in t2- Similarly, if there exists 
a potential undetectable backward shift of output d at port p from transition t2 
to transition ti, then, this potential shift may be realized in an implementation, 
by an extra output d at port p in t\ and a missing output d at port p in ^2- 

Therefore, one has to determine, for each pair of transitions t\ and t2 related 
to a potential undetectable shift of an output at a specific port p, whether there 
exists a missing/extra output at port p of transition t, for each transition t 
in tit2- In order to do this without using external coordination messages among 
testers, one has to determine whether there is a subsequence of transitions in 
the given FSM that will detect a missing/extra output at port p of transition t 
and then construct such a subsequence. Clearly, we also need to check whether 
every incoming transition of each state of the FSM forms a synchronizable pair 
of transitions with at least one of the outgoing transitions of that state and 
every outgoing transition of each state of the FSM forms a synchronizable pair 
of transitions with at least one of the incoming transitions of that state. If this 
condition does not hold, then the FSM is called intrinsically non-synchronizable. 
In this paper, we consider FSMs that are not intrinsically non-synchronizable. 

Hence, the problem we consider is the following: for each transition t in each 
pair of transitions t\ and t2 of the FSM related to a potential undetectable shift of 
an output at a specific port p, we wish to produce a single subsequence pi@t@p2 
that checks whether the output produced by t at p represents a missing/extra 
output at port p. In addition, the subsequence pi@t@p2 must have the following 
properties: it must be synchronized and it cannot contain an undetectable output 
shift fault involving t at port p. This places conditions on pi (called the leading 
path) and p2 (called the trailing path). We give conditions under which such pi 
and p2 exists. We also give algorithms that, when these conditions hold, generate 
Pi and p2 for given t and p. Where such subsequences exist for both t\ and t2 
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we say that they resolve the potential undetectable shift of the output at port p 
in t\t 2 - In the rest of the paper, we will not qualify a subsequence or sequence 
as “synchronizable” as only synchronizable sequences and subsequences will be 
considered. 



3.2 Conditions 

Suppose that two transitions in the given FSM may be sequenced in a manner 
that gives a potential undetectable shift of an output at port p. The following 
gives conditions under which these two transitions may be checked separately 
for a missing/extra output at p, without using external coordination messages, 
in a manner that does not allow them to be involved in an undetectable shift of 
an output at p. Further, it will transpire that under these conditions, this may 
be achieved for every pair tit 2 of transitions from the FSM. In Section 5 we will 
discuss how these conditions may be weakened when we are considering a given 
test or checking sequence derived from the given FSM. 

Given an FSM with no same-port-output-cycles or isolated-port- cycles, we 
can resolve all of its potential undetectable 1 -shift output faults without using 

external coordination messages if and only if for any pair of transitions Si — - — > s 

j 

and s > t\ in the FSM, 

a if there exists a potential undetectable forward shift of an output at port p, 
then there exists at least one transition to s with a null output at port p, and 
at least one transition from s with either an input or a non-empty output at 
port p. 

b if there exists a potential undetectable backward shift of an output at port p, 
then there exists at least one transition to s with a non-empty output at 
port p, and at least one transition from s with either an input or a null 
output at port p. 



Below we show that the condition for the case of potential undetectable 
forward shift (i.e. part a.) is necessary. The necessity of the condition for the 
case of potential undetectable backward shift is analogous. In Section 4 we will 
show how, under these conditions, the potential undetectable output shift faults 
may be resolved without the use of external coordination messages and thus that 
these conditions are sufficient conditions. 



Suppose we have transitions ti = si 



*/vi\pA 



and i 2 = s ^ Ti in 

the FSM of the specification where x ^ Ip. Thus, there is a potential undetectable 
forward shift of output d from ti to ^ 2 - 



x' jy' 

— Suppose that the condition does not hold, and Vs' such that s' !■ s, we 

have y' \p=f —. In this situation, the output at port p on any transition 
leading to s may be shifted to transition t 2 , and these potential shifts are 
undetectable. So we have no way to check that transition t 2 has null output 
at port p in the implementation, because no matter how we get to state s. 
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(a) 



(b) 



Fig. 1. illustration of the condition 



there is always a possibility of an undetectable forward output shift at port p 
to t2- 

— Suppose that the condition does not hold, and Vs' such that s — s', we 
have x' ^ Ip and y' |p= — . In this situation, the output d on transition t\ 
may be shifted to any transition starting from s, and these potential shifts 
are undetectable. So we have no way to check that transition t\ has output d 
at port p in the implementation, because no matter how we continue from 
state s, there is always a possibility of an undetectable forward shift of 
output d from ti . 



Figure 1 illustrates an example of a 2 -port FSM where the condition is satis- 
fied. In this figure, we have potential undetectable forward output shift fault in 
(a) and potential undetectable backward output shift fault in (b), as the dashed 
arrows show. For such potential faults, we have transition from S2 to s and tran- 
sition from s to ^2, so the condition holds. In fact, in (a), transition from s to X2 

will be used to check if there is a missing output d in transition si > s, 

as a result of a forward output shift. The transition from S2 to s will be used 

to check if there is an extra output in transition s — ri as a result of 
a forward output shift. The transitions from S2 to s and from s to V2 in (b) will 
be used analogously. 

Note that 



In Si — > g 5 — -tn (x ^ Ip), having checked that the first tran- 

sition does not have a missing output d at port p cannot guarantee that 
the second transition does not have an extra output at port p. In Fig- 

ure 2 (a), suppose that using S2 ^ ^ we know that 

in transition s — there is no extra output. However, we cannot 
jump to the conclusion that in si ^ — *■ s there is no missing output d, 



236 



Jessica Chen et al. 





(c) implementation (d) implementation 



Fig. 2. An example to show possible undetectable 1-shift output faults 



because Figure 2 (c) can be an implementation: Thus, we need to check 

)th transil 

h/<-,*> 



• • , ,, ,, 

both transition si > s for possible missing output d, and transition 



-> ri for possible extra output. 

The potential undetectable output shift faults may not be paired. In Fig- 
ure 2 , (a) may be implemented as in (d). Thus, we need to check transi- 

• ... . . 

tion Si !■ s for possible missing output d, and check both transitions 

s — ri and s — r’2 for possible extra output. 



When the above condition holds, given a transition t, we show below how to 
check if there is a missing output or an extra output at a specific port on this 
transition in the implementation. To do so, we construct a leading path p\ that 
leads to the starting state of t and a trailing path p2 that starts from the ending 
state of t so that by applying subsequence p\@t@p2 to the implementation, we 
can detect if there is a missing/extra output at a specific port in transition t. 

Note that we consider FSM with no same-port-output-cycles and no isolated- 
port-cycles. In this setting, our procedures to construct the leading paths and 
trailing paths will always terminate with subsequences that are adequate. 
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In Section 5 we will discuss the case where a test or checking sequence p has 
been given and we wish to produce subsequences to check for any 1-shift output 
faults that are undetectable in p. 

4 Generating Subsequences 

4.1 Checking the Potential Missing Data Output 

Given a transition t = s\ — - > S 2 (d yf — ), in order to check that there is no 
missing output d at port p in this transition in the implementation, we construct 
a leading path to si such that (i) it starts with a transition that has an input 
at port p; (ii) except for the first one, there is no other transition along the 
path that has an input at port p; (iii) on any transition of the path, there is no 
possibility of an extra output d at port p. 

The leading path should start with a transition which can be used to help 
identify the potential missing output d in transition t. Obviously, such a transi- 
tion should contain input or output at port p. Note that the leading path may 
be preceded in testing by other transitions that are capable of producing ex- 
tra output at p. Thus it is not sufficient to define a leading path starting with 
a transition that has non-empty output at port p: We require that the leading 
path start with an input at port p. Furthermore, to minimize the length of the 
leading path, we require that the input at port p at the beginning is the only 
input at port p in the leading path. We require that along the leading path there 
is no possibility of an extra output d at port p, because the occurrence of such 
an extra output d will prevent us from detecting the missing output d at port p 
in transition t. 

The following procedure constructs the leading path pi. 

i Let pi = e 

ii If the transition t has input G Ip, terminate as no leading path is required. 

iii Let = si 

j y cj 

iv If 3v'. v' ^ — > V and c yf — , then pi = {y' , v; /y'[p, c])@pi, terminate. 

Otherwise, let v' be a state such that v' > v and c yf — . Let pi = 

{v' , v; x/y'[p, c])@pi, v = v' , repeat iv. 

For the first time in step (iv), if 3v" . v " — > si, then there exists 

a potential undetectable backward shift of output d between v" — ' ^ > si 

and Si — - > S 2 . According to our condition b., 3v' . v' — - > si and c yf — . 
The same argument holds for the repeated step (iv). Thus, in (iv), the existence 
of v' is guaranteed. Termination, with an adequate leading path, is guaranteed 
because M must be free from same-port-output-cycles. Further, since M has no 
same-port-output-cycles this procedure cannot repeat a state of M and thus, 
if M has m states, the leading path can have length at most m — 1. 
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At the end of the procedure, we have a leading path that, if it is non-empty, 
starts from a transition with an input at port p, followed by transitions with 
non-empty outputs at port p. Any of these outputs at p can be missing, but 
there is no possibility of an extra output at p. 

Note that these outputs at port p can be d, and so, although there is no possi- 
bility of an extra d at port p, there exists possibility of a missing d in the leading 
path. So if a missing d at port p is detected, we may not be able to tell which d is 

missing: from a transition in the leading path or from transition si — - > S2- 
Additional conditions might be added to avoid this from happening. An example 
of such a condition is: no two consecutive transitions have the same output data 
at the same port. 

The construction of the trailing path is quite similar: Given transition 

— /y^P’ j ^ ^ order to check that there is no missing d in this 

transition in the implementation, we construct a trailing path starting from S2 
such that (i) it ends with a transition that has an input at port p; (ii) except 
for the last one, there is no other transition along the path that has an input 
at port p; (iii) on any transition of the path, there is no possibility of an extra 
output d at port p. 

The following procedure constructs the trailing path p2- 

i Let P2 = s, V = S2 

ii If 3w'. V >v' for some input Xp G Ip, then p2 = p2@{v,v']x’^ly'), ter- 

minate. 

Otherwise, let v' be a state such that v > v' and c yf — . Let p2 = 

P2@{v,v' ]x/y'[pTc\), v = v', repeat ii. 

Again, this must terminate, with an adequate trailing path of length at most 
m — 1. 

4.2 Checking the Potential Extra Data Output 

Given transition si — — > S2, in order to check that there is no extra output 
at port p in this transition in the implementation, we construct a leading path 
to Si such that (i) it starts from a transition with an input at port p; (ii) except 
for the first one, there is no other transition along the path that has an input 
at port p; (iii) on any transition of the path, there is no possibility of a missing 
output at port p. 

The following procedure constructs the leading path pi. 

i Let Pi = e 

ii If the transition t has input xP G Ip, terminate as no leading path is required. 

iii Let w = si 

iv If 3u'. v' ^ — >v, let Pi = {v' ,v, xP /y'[p, —])@pi, terminate. 

^ j p j 

Otherwise, let v' be a state s.t. v' ^ — > v. Let pi = {v' , v, x/y'[p, — ])@pi, 

v = v' , repeat iv. 
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For the first time in step (iv), if Bv". v" — - > si where c yf — , then there 

exists potential undetectable forward shift of output c between v" — - > si 

and Si ^ — > S2- According to our condition a., Bv' . v' ^ — > si. The same 

argument holds for the repeated step (iv). Thus, in (iv), the existence of v' is 
guaranteed. Termination , with an adequate leading path of length at most m— 1 , 
is guaranteed because M must be free from isolated-port-cycles. 

The leading path, if it is non-empty, starts from a transition with an input 
at port p, followed by a sequence of transitions with empty output at port p, 
and so there is no possibility of missing output at port p along the leading path. 

The construction of the trailing path is similar: Given transi- 

tion Si — j > in order to check that there is no extra output at port p 
in this transition in the implementation, we construct a trailing path from S2 
such that (i) it ends with a transition with an input at port p; (ii) except for the 
last one, there is no other transition along the path that has an input at port p; 
(iii) on any transition of the path, there is no possibility of a missing output at 
port p. 

The following procedure constructs the trailing path p2- 



i Let P2 = £, V = S2 

j y' 

ii If Bv' . V > v' for some G Ip, let p2 = P2@{v, v'] terminate. 

j y ] 

Otherwise, let v' be a state s.t. v ^ — > v' . Let p2 = P2®{v, v'] x/y'[p, — ]), 

V = v' , repeat ii. 

Clearly, this must terminate, with an adequate trailing path of length at most 
m — 1. 

5 Concluding Remarks 

Where a test architecture has remote testers it is necessary to consider controlla- 
bility and observability issues. These problems often require the use of external 
coordination message exchanges among testers during testing. However, there is 
often a cost associated with the use of such messages: the cost of implementing 
the infrastructure required in order to allow the messages to be sent and possibly 
also a cost (or delay) due to the sending of each message. It is thus desirable to 
construct a test or checking sequence from the specification of the system under 
test such that it will be free of controllability and observability problems without 
requiring the use of external coordination message exchanges. 

This paper investigates conditions that must be satisfied by the specification 
of the system under test for us to be able to produce a test for each transitions 
such that the test is free from controllability and observability problems. This 
problem is represented in the following way. 

For each potential undetectable 1 -shift output fault in the FSM, we have 
a pair of transitions t\t2- For each transition t in t\t2, we wish to produce 
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a single subsequence pi@t@p2 that checks the output produced by transition t 
at port p. It is necessary to precede t by some appropriate sequence as the 
starting state of t must be reached in order to execute t and the sequence used 
to reach this state must not be able to lead to a potentially undetectable shift 
of the same output involving t. It is necessary to follow t with some appropriate 
sequence since we must ensure that the sequence following t does not allow 
a potentially undetectable shift of the same output involving . The effectiveness 
of the subsequence pi@t@p2, at checking the output of t at p, must not be affected 
by controllability and observability problems. This paper gives necessary and 
sufficient conditions for there to be such a subsequence for each t in a pair of 
transitions tit2 representing a potential undetectable output shift fault related 
to an output at port p. Further, given a transition t and port p, we have given 
algorithms that (if these conditions hold) produce a subsequence that checks the 
output of t at p without suffering from controllability and observability problems. 

In practice, weaker conditions than those given in this paper will often suffice 
since: 

i it may not be necessary to consider all pairs of transitions; and 
ii it may be possible to use more than one subsequence to check a transition t. 

We will now briefly discuss these factors. First, we may be concerned with 
potential observability problems in a given test or checking sequence p. Since 
some transition pairs representing potentially undetectable output shift faults 
may not be in p and since the paths leading to and trailing from those t\t2 
pairs in p representing potential undetectable output shift faults are already 
determined in p, weaker conditions may suffice. 

Suppose that p contains the subsequence t\t2 for transitions t\ and t2 and 
that these can participate in a potentially undetectable 1 -shift output fault at 
port p. Sometimes we can eliminate this potentially undetectable 1 -shift output 
fault by using a subsequence that checks the output of t\ at p or a subsequence 
that checks the output of ^2 at p but not both. We now explain why this is the 
case. Suppose that we test the output of at p and find this to be correct; the 
case where we have checked the output of t2 at p is similar. If we know that the 
subsequence tit2 produces the (overall) correct output at p then we also know 
that t2 produces the expected output at p. Naturally, further conditions must 
be placed on p in order for it to determine the overall output of t\t2 at p in the 
SUT. 

This paper has investigated conditions under which it is possible to resolve 
potentially undetectable output shift faults. However, a number of questions re- 
main. As already noted, weaker conditions sometimes suffice - the challenge is to 
produce general necessary and sufficient conditions. Suppose we produce a sub- 
sequence for each transition/port combination and generate a single sequence 
p that contains each of these subsequences. Then p is guaranteed to determine 

^ Sometimes it is possible to separate several test or checking sequences using a reset. 
Where this is the case, under certain conditions it is possible to replace p2 with 
a reset. 
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correctness under the fault model in which only output faults are possible. How- 
ever, this need not be an efficient sequence for this fault model. There is also the 
problem of producing an efficient test or checking sequence, from an FSM, that 
is guaranteed to determine correctness for more general fault models. 
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Abstract. Flexible Architecture for Multiple Environments (FAME) is Bull 
architecture for large symmetrical multiprocessors based on Intel's Itanium® 2 
family, which is used in Bull NovaScale® servers series. A key point in the 
development of this distributed shared memory architecture is the definition of 
its cache coherence protocol. This paper reports experiences and results of 
integrating formal verification of FAME cache coherence protocol, on 4 
successive versions of this architecture. The goal is to find protocol definition 
hugs (not implementation) in the early phases of the design, focusing on: cache 
coherency, data integrity and deadlock-freeness properties. We have performed 
modeling and verification using Murtp tool and language, because of its 
easiness of use and its efficient state reduction techniques. The analysis of the 
results shows that this approach is cost-effective, and in spite of the state 
explosion problem, it has helped us in finding hard-to-simulate protocol hugs, 
before the implementation is far ahead. 



1 Introduction 

Design and verification of complex systems are an outstanding application domain of 
formal methods. Cache coherence protocol of symmetric multiprocessor (SMP) over a 
distributed architecture is indeed a very complex system, where concurrency of 
transactions issued by different agents and the resulting conflicts are very difficult to 
master and verify without the help of rigorous analysis. Such help is provided by 
formal methods that allow to describe behaviors in a precise unambiguous language 
and to automatically prove properties of these descriptions. 

Flexible Architecture for Multiple Environments (FAME) is Bull architecture to 
design large SMPs that can include up to 32 processors [4]. It is based on Intel 
Itanium®2 family and commercialized in the Bull NovaScale® server series [1]. This 
non-uniform access memory (NUMA) distributed shared memory multiprocessor is 
organized in modules managed by a key component, the FAME Scalability Switch 
(FSS). A FAME machine is obtained by connecting up to 4 modules, through an 
interconnection network that links the FSSs (Fig. 1 shows the module structure). 

From the very beginning of this project we have applied formal protocol 
verification to the cache coherence protocol of 4 successive versions of this 
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architecture. (Formal verification results of the first version are partially mentioned in 
[15].) 




Fig. 1. FAME module architecture. Each module contains processor nodes and lO nodes that 
are connected by a switch called FAME Scalability Switch (FSS). Here a module contains 2 
processor nodes and two lO nodes, a processor node contains four processors and a memory 
subsystem 

Our goal is to apply formal verification as a design aid [3], in order to find protocol 
definition bugs (not implementation) in the early phases of its specification and to 
increase confidence in its correctness. Protocol specification verification differs from 
other formal verification activities that address hardware implementation correctness, 
like formal verification of properties of the register-transfer level (RTL) descriptions, 
or equivalence checking between RTL and gate levels. Starting from a reference 
specification we build an abstracted, simplified and downsized model of the protocol 
and check that it verifies some properties. As we will see, this approach is cost- 
effective and allows finding hard-to-simulate protocol bugs before the implementation 
is far ahead, in spite of state explosion problem. 

Among all requirements that must be implemented by FSS, we focus on the 
essential function of keeping memory coherent, which is ensured by the cache 
coherence protocol. Thus, formal modeling and verification address this protocol, 
focusing on coherence handling aspects, abstracting anything else, like routing, 
networking and resource management. 

In order to show the complexity of the problem addressed. Section 2 gives an 
overview of a distributed cache coherence protocol like FAME'S one, highlighting the 
main issues (conflict handling, race conditions and data integrity) and defining the 
properties we aim to check. Based on these properties. Section 3 states and informally 
justifies the protocol abstractions done in the modeling process: event aggregations 
and resource simplifications. Then in Section 4, we summarize the features of Munp 
language and tool, which have made us choose it to model and verify our cache 
coherence protocol: amenity of the language, shortest explicit error traces, efficient 
state reduction techniques (symmetry and hash compaction) and asynchronous 
semantics. In Section 5, we analyze the results obtained in the modeling and 
verification of the four versions, from two viewpoints: the incremental modeling and 
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verification process, and the cost-benefit Figures. Finally we draw our conclusions 
from this experience, summing up the benefits of this approach. 



2 FAME Cache Coherence Protocols Issues 

In order to give insights of the complexity of the addressed problem, we describe the 
features of cache coherence protocols in distributed shared-memory architecture [7]. 
We give some information on FAME protocol specifically, without disclosing the 
details of this proprietary protocol. 

2.1 Distributed Cache Coherence Protocol 

A private cache is associated to a processor in order to reduce the effects of memory 
access latency and contention. In shared-memory multiprocessor, a memory location 
can be present in several caches, thus introducing a consistency problem. A cache 
coherence protocol ensures that memory is kept coherent, that is, any change made to 
a memory location is made visible to all other processors. A common solution is to 
associate to each cache line (transfer unit between memory and caches) a state and 
associated access rights. When a processor initiates an access compatible with the line 
state, it is performed in the cache (it is a hit)’, otherwise it issues a transaction on the 
bus (it is a miss). 

In writeback caching policy, all processor loads and stores are performed in the 
cache: thus even when a processor needs to write a location, first it fetches in its cache 
the memory line that contains this location, invalidating all the other caches {read 
with invalidation request). Replacement occurs when a processor needs to put a new 
line in its cache, and all the entries that it can fit in (depending on the organization of 
the cache) contain valid lines: then a replacement algorithm selects a line to be 
evicted from the cache: if it is not modified, this can be done silently; otherwise, a 
memory update request is sent to memory. 

FAME protocol is based on the classical 4-state protocol called MESI [12] 
(acronym formed by the state initials): M (modified line, this cache owns the only 
valid copy of the system, and any access by its processor is a hit; this cache is 
responsible of providing data to other caches), E (exclusive, this cache is the only one 
to hold a copy, but it is the same as in memory; any access is a hit and a store will 
change it to M), S (shared line, it can be present in other caches, and data value is the 
same as in memory; a load causes a hit, but a store causes a miss), I (invalid line: not 
present or present but stale; any access is a miss). (Sometimes, M state is called dirty 
in the literature). 

A cache coherence protocol defines the rules of handling the requests issued on a 
miss: how to get information on all cache states, cache state transition rules, where 
and how to send requests, where to find data, collision handling (concurrent requests 
to the same line). There are two basic kinds of protocols: snoopy-based and directory- 
based protocols. 

In a snoopy-based protocol, any request is snooped by all processors and memory, 
and their responses are also snooped in a synchronous way: thus memory and cache 
controllers have all needed information in a synchronous way and can take 
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appropriate actions. This protocol is suitable for a bus-based architecture and does not 
scale to distributed systems. 

In a directory -based protocol, the original idea is a directory that indicates for any 
line contained in a processor cache, its state and the list of caches that contain it. In 
distributed shared-memory architecture, where there is a virtual unique global 
memory address space but memory is physically distributed, each memory piece has 
its associated directory. Then on a miss, a request to a line mapped in a memory slice 
(called the home memory of the line) is sent to its attached directory, which forwards 
request to the concerned caches, instead of the bus-broadcast scheme in snoopy-based 
case. Actually these directories can be distributed in various ways including grouping 
some of them in one directory or defining directory hierarchy. 

As in caches, there are also replacements in directories: when a an entry holding 
the state of a line has to be evicted out of the directory, then the directory sends 
invalidation requests to all the caches that hold a copy of this line. 

Often in actual implementation of distributed shared memory architecture, both 
kinds of cache coherence protocol are combined. In FAME, within a processor node, 
there is a bus-based snoopy-protocol that interacts with a directory based protocol at 
the module level. All directories are grouped in FSS. 

2.2 Cache Coherence Correctness Properties 

A cache coherence protocol aims to keep memory coherent not to implement some 
memory consistency model, like sequential or processor or weak or release 
consistency. Any memory model assumes basic memory coherency that is: all writes 
to the same memory location are seen in the same order by all processors [6] 
(otherwise, you cannot even implement a lock; notice the difference with sequential 
consistency for instance, where the set of accesses to all memory locations is seen in 
the same order by all processors). 

Therefore, the properties to verify are: 

1. Cache and directory state coherency, following the definition of the MESI 
states: for instance, when a line is E/M in some cache, it is I elsewhere. Since 
directories contain information about caches, there are inclusion relations 
between cache state and directories. When there is directory hierarchy, there are 
inclusion relations between directories. 

2. Data integrity: a processor does not read stale data and no data modification is 
lost. This requirement is not implied by cache state coherency. For instance, as 
said above, a memory update is performed when a cache evicts a line in M 
state. After the eviction all caches are I (so the states are coherent), but there is 
an ongoing memory update. If a read request issued by a processor can get to 
memory before the update (race condition between read and write), it will get 
stale data. 

3. Deadlock- freeness: actually, a lot of deadlock and starvation issues are related 
to resource management and so are implementation-dependent. Still, at the 
protocol level, we have an abstract view of outstanding resources that are used 
to handle coherency like directories and buffers that track request progression. 
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Besides, deadlock issues rise in coherence conflict resolution policies, where a 
colliding request can be held-off or retried. 

2.3 Cache Coherence Issues 

The main behavior issues of a cache coherence protocol, which we derive from the 
properties to verify, can be summarized as follows: 

1. Basic transaction handling. What are the transactions of the protocol, how is 
memory updated, where to find up-to-date data? As hinted above, there are 
several types of transactions: read, read with invalidation, invalidation, memory 
update, etc., and each type has a particular cache and directory state transition 
rule. In FAME we have up to 10 transaction types. 

2. Conflict resolution rules, which should ensure coherence without deadlock. A 
key issue of distributed directory-based cache coherence protocols is conflict 
resolution. Two concurrent requests issued by two processors are said to be in 
conflict (or to collide) if they are to the same address. In a snoopy-based 
protocol, the bus grant serializes accesses in an atomic way thus resolving 
conflicts: request emission is serialized’, requests and responses are snooped 
synchronously by all the caches. But in distributed protocols, requests are 
issued concurrently, there are multiple conflict points (where conflicting 
requests meet) and various race conditions arise between requests or between 
requests and responses. For instance in FAME, within a module, a processor 
node can send requests to FSS and vice-versa, and there are requests between 
FSSs of different modules: then conflict points are in processor nodes and in 
FSS (where there are several types of conflicts depending on the request 
source). Thus, two concurrent conflicting requests that are issued by nodes in 
different modules can collide in either requesting node or in either FSS of both 
modules. Conflict resolution is complicated by race conditions: request and 
response channels are independent, so a request can overtake a response and 
vice-versa. For instance, if a node controller sends a request Rql to FSS, then 
FSS sends its corresponding response Rsl followed by a request Rq2: the node 
controller may receive Rq2 before Rsl, without knowing whether its request 
has been acknowledged or not. There are similar race conditions in transfers 
between modules. 

3. Directory replacement handling, in relation with conflicts and deadlocks. For 
instance, if a request on address A is received by a directory and it needs to 
cause a replacement in order to complete, if B is the line that is chosen to be 
evicted (and so invalidated) it may mn into a coherence conflict with a pending 
request to B. Thus, the replacement triggering creates a connection between 
two requests on different addresses through resource (directory) and coherence 
conflict, which may cause deadlocks. 

3 Protocol Behavior and Property Modeling 

We aim to build a reduced model at the “right” abstraction level, trying to find a 
compromise between what is tractable and what is needed to verify cache coherence 
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properties. The behavior details which are not related to the cache coherence protocol 
issues and properties brought out above are dropped. 

3.1 Behavior Modeling 

There are mainly two kinds of simplifications that are combined in modeling: 

1. Aggregating a sequence of events in one atomic event. This means that the 
intermediate states between the aggregated events are not observable and some 
orderings are not possible in the model. 

2. Reducing the resources of the system. This involves reducing the elements of 
the system: determining the number of processors, nodes, modules, memory 
addresses, choosing which tables or queues are to be modeled, and what 
information they contain is needed to model the behavior we want to verify. 

Event Collapsing 

As said above, the main issue of a cache coherence protocol is conflict resolution, and 
conflicts results from the concurrent behavior of the different agents of the protocol 
and race conditions between request/response transfers. So the abstraction, 
particularly the event collapsing one, should capture this concurrency, so that all 
kinds of conflict be possible in the model. 

This is the general event aggregation scheme: a transaction goes through different 
phases incurring treatment in each agent (processor, node controller, FSS) and 
transfers between agents. We consider that there are three “treatment centers”: the 
processor bus including the caches within the node, the node controller, and FSS. We 
can collapse several steps as long as there is no more than one transfer involved 
between these centers. There are 3 kinds of transfers: between the processor caches 
and the node controller, between the node controller and the FSS buffers and between 
two FSS buffers. A typical case is collapsing emission or reception of a transaction 
with its handling. An agent receives a transaction, then handles it (performing some 
treatment), then sends a result. We can collapse receiving the transaction and handling 
it in one event, or handling the transaction and sending the result. If we collapse the 
three events we could miss conflicts between several transactions received, or we 
miss some orderings like: a transaction T1 is received before T2, but the results of T2 
is sent before that of Tl. 

Thus, considering that transfers between the agents are atomic and point-to-point, 
discarding the interconnection network and routing functions, does not miss the 
requests and responses concurrency from the coherence protocol viewpoint. This 
assumes we use a formalism based on asynchronous interleaving semantics. 

So, in our models, events will be either internal events to caches or FSSs, or 
request/responses transfers with the associated treatment at the reception point. 

Resource Reduction 

The objects that are modeled are: caches (state and data), memory, node controller 
and FSS directories. Within nodes and modules, we represent the buffers that keep 
track of requests, sometimes collapsing several buffers in one. 
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Concerning, the number of memory line addresses, since the aim of a cache 
coherence protocol is memory coherency and not some consistency model, it is 
enough to perform verification with only one address [8]. This remains true for 
directory replacements, if they are modeled as non-deterministic events, as long as 
only coherence aspects are considered. However, we aim to capture some deadlock 
issues related to the resources present in the model, and as pointed above, coherence 
and resource conflict meet in directory replacements. Therefore, we set the number of 
addresses to 2 when we want to take replacements into account; otherwise we set it to 
1 . An additional reason, for using 2 addresses in replacements, is to model conflict 
rules specified by the protocol as they are without introducing modeling bias. (In our 
models, when there are 2 addresses they are mapped to the same home memory). 

Beside varying the number of addresses, in order to perform incremental 
verifrcation and be able to vary the configuration of the model in facing state 
explosion, we need facilities to set these parameters (a home node or module, is the 
one that contains the home memory): 

• Number of processor nodes in a module, number of caches per node. 

• Number of memory line addresses in the system. 

• Sizes of the different buffers. 

• Number of active nodes in home/non-home module: so that we can set a model 
where one node is active in home module and 2 nodes in non-home module, for 
instance. 

• Option to prevent nodes in home or non-home module from issuing requests. 

• For each kind of transaction, a switch to enable it or not (as said above, there is 
up to 10 kinds of transactions in FAME). 

Caches, controllers, FSSs, modules, addresses, buffer index are all symmetrical 
types. Even if some node is home and the others not, we define the fact of being home 
as a boolean attached to a node, then this boolean can be set non-deterministically at 
the initial state. Then, in order to take advantage of these symmetries that allow 
reducing the state space, we need a tool that implements symmetry reduction 
techniques. 

3.2 Property Modeling 
Cache Coherence Properties 

Cache coherence properties are typically state invariants. The fact that there may be 
transient states where a directory is not accessible and coherence is not maintained is 
included in the property. Such transient state could be, for instance, that a transaction 
is ongoing in some buffer. Then the cache coherence property is: we are in a transient 
state OR the coherence relation is true. An example of coherence relation: if one 
directory state is E, then all other directories states are I. 

Valid Data Properties 

In order to verify that a processor does not get stale data and that no data 
modifications are lost, we use a data model (borrowed from [13]) that avoids 
manipulating data values. 
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Data are modeled with two values: valid and invalid. When a proeessor writes a 
line, this eopy takes the value “valid” and all other eopies of the same address in the 
system become “invalid”. These copies are in memory, caches, and buffers that keep 
track of requests and hold responses. This implies the ability to manipulate global 
variables. Then, to verify data integrity, we add these state invariants: 

• If a cache is not I, it contains valid data. 

• When there are no modified data in a cache, data in memory are valid. 

Deadlock-F reeness 

The actual deadlock-freeness property one expects from a real system is: “a 
transaction will always inevitably complete (within a bounded time)”. But since we 
deal with abstract models that do not describe arbitration and starvation prevention 
mechanisms, and we use asynchronous modeling where it is possible to indefinitely 
delay the firing of a transition, the general property we would like to verify is: 
“always, whatever the point it has reached, a request can be completed”. The different 
cases of request non-termination are: it has gone into a livelock, or it is stopped 
somewhere. 

4 Murtp Language and Tool 

Choosing a notation and its associated tool depends on the goal and the application 
domain. A comprehensive survey on verification methods for cache coherence 
protocols is given in [14]. Since we deal with complex specification of cache 
coherence protocol in distributed shared-memory architectures, and we focus on 
mastering the specification and finding bugs rather quickly, methods based on explicit 
state enumeration are more suitable: because, verification is fully automatic, and 
error traces can be minimal and explicit, giving a scenario showing the error origin. 
Efficient state reduction techniques are indispensable to take into account the minimal 
concurrency we need to verify conflict issues. These considerations have led us to 
choose to use the Munp language and tool developed by the Hardware Verification 
Group of Stanford University [9]. 

Amenity of the Language and Specification Style 

Munp provides familiar data structures and programming constructs. For instance, 
there are types such as record and arrays that can be indexed over an enumerated type, 
imperative programming constructs such as if-then-else, switch, for, while... Besides, 
it is possible in Munp to define constants that are parameters of the system: number of 
addresses, of processors, etc... So, we can change the configuration of the model by 
changing these constants and recompiling. 

Building a model consists in defining a collection of global variables, which 
represent the system resources states and a collection of transitions rules. Each rule 
has an enabling condition, which is a boolean expression on the state variables, and an 
action, which is a sequence of statements that modify the values of the state variables, 
generating a new state: rule condition ^ action statements endrule. A rule is 
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symbolically defined with parameters: it represents a set of instantiated rules. In a rule 
we can access any global variable. 

If the global variable concept does not seem suitable to an architecture reference 
specification, it is an important mean of abstraction and state reduction in a model 
intended to verify the main points of a protocol. We use this global variable access 
feature in the verification of valid data property (Section 3.2): if caches, node 
controllers and modules were modeled as processes with local variables that are not 
accessible globally, we would not be able to simply model this property. 

State Reduction Techniques 

Murtp provides several state reduction techniques: 

The undefine statement allows to give a nil value to a variable thus identifying 
irrelevant values at some point. This reduces the number of states since it avoids 
having two states that differ in non-relevant parts. In one of our verification tasks, 
forgetting to undefine a variable at some point has multiplied the state count by 10. 

The symmetry reduction [1 1]: a special type constructor, scalarset, can be used 
to define a set of symmetrical identifiers (so it is user-provided symmetries). For 
instance, we declare the types of processor identifiers as scalarset. Then, in the 
state enumeration process, if a state can be obtained from another one by permuting 
the values of scalarset types, then both states are considered equal. As the 
complexity of trying all possible permutations may become exponential, there are 
options to limit the number of permutation trial or to use fast heuristic normalization 
algorithms. 

Bit-compaction consists in compacting the state descriptor into a bit-string without 
loss of information. This reduces the state space but increases computing time. 
Generally, this reduction is not enough for complex configurations and we rather use 
the hash-compaction option detailed in the next point. 

Probabilistic verification or hash compaction', instead of storing the whole state 
descriptor, a hash compacted descriptor is stored (typically on 40 bits). Thus, different 
states could be considered equal. In the verification status, the verifier prints the 
probabilities of having missed one state or one error [16]. 

Asynchronous Behavior 

The Murcp language is asynchronous without a clock and without event duration. Its 
fundamental semantics is that of a transition system: there are events (transitions) that 
can occur when some enabling condition is true, and one event occurs at a time (no 
simultaneous events). The occurring of an event leads the system from a state to 
another one. This is insufficient if we want to describe and analyze the low-level 
design of a hardware piece (RTL level). But it is necessary abstraction means to 
describe system level protocol transactions, where we need an abstract way to 
describe all possible interleavings of events due to variable delays and different paths 
without describing the implementation details. 

Verification and Error Diagnosis 

The semantic of the model is the reachability graph of the transition system. A state is 
an assignment of the global variables. A rule is an atomic event. The graph is 
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produced by an explicit state enumeration: beginning with an initial state, all the 
enabled rules in this state are executed yielding the successors states of the initial one. 
And this process continues with the generated new states, etc. 

The properties to verify are expressed as boolean expressions and incorporated in 
the model: 

• State invariants: boolean expression on global variables that should be satisfied 
by all the reachable states. 

• “Assert” instructions: boolean expressions that should be true in some point 
during the execution of a rule. 

Murcp compiler transforms a model into a C++ program, the verifier that explores 
the state graph. When an error is found, the verifier halts and prints an error trace. 
There are 4 kinds of errors: 

• A reachable state that violates an invariant. 

• An assert instruction result is false during the execution of a rule. 

• An undefined variable is accessed during the execution of a rule: this could 
indicate an uncovered case in the protocol definition. 

• A deadlock is reached: a state that has no successors (no rule is enabled). 

Since we always use breadth-first search option, the error trace is a minimal one, 
producing a scenario leading from the initial state to the state exhibiting the problem. 
So, errors can be found quickly without the need to totally explore the state graph: 
this moderates state explosion problem consequences on finding errors. 



Murcp Choice Motivation Discussion 

Among all Murcp advantages listed above, the determining choice factors are 
symmetry and hash-compaction reductions, which have allowed us to verify fairly 
huge models (see Section 5.1, particularly Table 2 and its comment). Then the 
drawback is that liveness property verification is not supported with symmetry 
reduction. 

In [5], a similar protocol to ours is model-checked using Cospan, SPIN and Murcp: 
the results demonstrate also the benefits to exploiting symmetries with Murcp. 

However, even if we cannot verify deadlock-freeness properties like “always a 
transaction can complete” (Section 3.2), we can verify that there is no total system 
deadlock (a state where no event can occur). This is a sub-case of the liveness 
property we aim to, but benefits outweigh this disadvantage since we mainly focus on 
coherence properties and at least sink states can be detected (the limited resources of 
the model often make a blocked request result into a total deadlock). 

(In a previous experiment, we had other property constraints and it was suitable to 
use LOTOS [2].) 

5 Verification and Modeling Outcome 

We have applied protocol formal verification to four versions of the FAME cache 
coherence protocol, which we call: FVl to FV4. In FVl, modeling started at the very 
beginning of the cache protocol definition when it was still early thoughts, and went 
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along its specification process. FV2 was a major revision, impacting transaction and 
conflict handling: in this case, formal modeling and verification started when the 
protocol definition was fairly mature but not finalized yet. FV3 has kept basic 
transaction handling but introduced a significant modification in conflict handling. 
FV4 had no significant impact on coherence protocol, but the evolutions were related 
to routing and system scaling: new protocol cases were added by this change but the 
transaction and conflict handling is the same. 

In order to assess this experience, we examine two aspects: the modeling and 
verification process and the cost-benefit analysis. 

5.1 Incremental Modeling and Verification 

FAME Munp models conform to the principles stated in Section 3. The global 
variables are: modules, each module contains FSS and processor nodes, FSS contains 
directories and buffers for ongoing transactions. A processor node contains memory, 
caches and input/output buffers of node controller. The cache states, data values, 
request and responses types are defined as enumerated types. The structures are 
defined as records and arrays. Identifiers of caches, nodes, addresses, and buffer index 
are defined as scalarset (symmetrical types). Replacements in caches are non- 
deterministic, but directory replacements occur only when needed and in models with 
2 memory line addresses. 

The model can be parameterized in order to define the configuration to be verified: 
the parameters are those listed in Section 3.1. There are 13 rules corresponding to: 
internal processor events, bus events within a processor node, transfers within a 
module, internal FSS events and transfers between two modules. The properties of 
interest (data integrity and cache coherence) are modeled as described in Section 3.2: 
there are 5 state invariants about directory coherence. 

The process interleaves modeling and verification. From the protocol definition 
specification, we build a first incomplete model and run verification. If an error is 
found, if can be a modeling bug or a protocol bug. So we are concurrently debugging 
our model and verifying the protocol definition. Then we make corrections or add 
new features to the model. Even if we know that a configuration is tractable by the 
verification tool, we should begin verification with the smallest model and increase 
sizes of the different parameters in stages: because the same error is longer to detect 
on a larger configuration than on a smaller one. 

Table 1 shows for each protocol major revision (FVl to FV4), the number of Munp 
model versions and the corresponding number of lines of code (LOC). For each case, 
there is a new model version at three points: model bug detection, protocol bug 
detection or new feature introduction in the incremental modeling process. So it is 
related to modeling effort and to issue finding. This explains why there are so many 
versions in FVl, where modeling started on early protocol definition and a lot of 
issues were detected, and why so few ones in FV4, where there are no protocol 
significant modifications and no error detected (see next subsection). The model sizes 
are similar and tantamount to a few thousands lines. 

Table 2 shows the largest graphs that could be reached by the verification without 
state explosion. For each case we give the figures for the largest configuration with 1 
memory address (so without directory replacement) in the model and the largest one 
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with 2 addresses (with direetory replaeement). In FVl ease, we were using a maehine 
with a 256MB memory, so it was not possible to go very far, while in the other 
experiments, the maehines used had 1 GB of memory. Therefore FVl largest graphs 
are not eomparable to the other graphs and are not reported here. 



Table 1. Incremental modeling effort 



Case 


Model versions eount 


LOC (smallest biggest) 


FV 1 


41 


920 ^ 3820 


FV2 


36 


1700 ^ 2750 


FV3 


15 


2643 ^ 3266 


FV4 


4 


3322 ^ 3459 



The features of the verifieations shown in Table 2 are: FV2a: 1 module, 4 
proeessor nodes, 1 eaehe per node, 1 address, 6 transaetion types. FV2b: 1 module, 3 
proeessor nodes, 1 eaehe per node, 2 addresses, 5 transaetion types. FV3a: 2 modules, 
2 nodes/module but only 3 modules aetive in the system, 1 eaehe/node, 1 address, 7 
kinds of transaetions. FV3b: 2 modules, 1 node/module, 1 eaehe/node, 2 addresses, 7 
kinds of transaetions. FV4a: 3 modules, 1 node/module, 1 eaehe/node, 1 address, 7 
kinds of transaetions. FV4b: 3 modules, 1 node/module, 1 eaehe/node, 2 addresses, 4 
kinds of transaetions. Even when there are 2 addresses, a node ean have at most one 
pending request. FSS buffer sizes are set, so that it ean reeeives all node requests 
eoneurrently. Obviously, inereasing the number of request sourees (eaehes, nodes) has 
more impaet than inereasing the number of transaetion types or addresses, sinee it 
inereases eoneurreney in the system. 

Notiee that these are the states explored taken into aeeount symmetries, so they are 
not all the states of the underlying graph explored. The graph diameter is a hint about 
the longest transaetion path. The CPU time may be different even for similar eounts 
of states for the same model, beeause with different parameters eonfigurations, the 
non-eompaeted state sizes are different. Generally, enough early in the proeess, we 
have to use Murcp hash eompaetion to avoid state explosion and so perform 
probabilistie verifieation (aetually we eombine bit-eompaetion and hash eompaetion). 

Table 2. Largest graphs. All this information is provided by Murcp. The “States” column gives 
the number of states explored. “Rules”: number of rules fired. Bounds of omission probabilities 
induced by hash compaction: Pi is probability of ’’even one omitted state”; P2 of “even one 
undetected error”. P<=0.000000 does not mean P=0, but that the bound of P, when rounded to 6 
digits, gives 0. Diameter is the one of the reachability graph. CPU time is expressed in days 



Case 


States 


Rules 


Probabilities bounds 


Diameter 


CPU (d) 


FV 2a 


54,842,173 


316,784,167 


PK=0.000024 

P2<=0.000000 


114 


3.1 


FV 2b 


59,069,095 


367,365,869 


PK=0.000029 

P2<=0.000000 


91 


1.5 


FV3a 


12,732,647 


55,006,883 


PK^O.OOOOOl 

P2<=0.000000 


76 


0.4 
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FV 3b 


53,908,283 


319,449,256 


PK=0.000013 

P2<=0.000000 


91 


1.5 


FV 4a 


23,203,144 


100,615,496 


PK=0.000006 

P2<=0.000000 


82 


2.3 


FV4b 


48,418,599 


301,928,790 


PK=0.000025 

P2<=0.000000 


89 


7.5 



These reduetion teehniques (symmetry and hash eompaetion) are indispensable to 
extend the limit where state explosion oeeurs and has allowed us to obtain the results 
we analyze in next subseetion. 



5.2 Cost-Benefit Analysis 

Sinee our goal is to find protoeol definition issues, the benefits ean be measured by 
the number of issues raised by modeling/verifieation aetivity. The eost is measured by 
the number of person. week needed to perform this task (aetually the work was 
aehieved by one person, the author). A protocol issue can be found either by the 
verifier or as a result of the modeling and abstraction activity. Modeling induees a 
thorough analysis of the protoeol definition that ean lead to finding issues, helping in 
elarifying, eompleting and mastering its speeifieation. 

When we run verifieation, there are 3 possible outeomes: 

• It is eomplete with no error found: then we go into another modeling/verifying 
eyele by adding features to the model or rerun the same model by ehanging the 
eonfiguration parameters. 

• An error is found and a traee error is produeed: then we eheek whether it is a 
protoeol error or a model error. In order to get shortest error traees, we always 
use breadth-first seareh. 

• The graph exploration eannot be eomplete due to memory lack (state 
explosion): then we use probabilistic verification, we try other configurations 
by tuning the model parameters, or we give up if we have already tried this. 

We classify the issues following 2 criteria, its category and finding origin [10]: 

1 . Category of the issue: there are three kinds of issues: 

• Uncovered or undefined case: the specification does not define the behavior of 
the protocol in this case. 

• Ambiguous specification: several interpretations of the specification are 
possible. One of these leads to an error. 

• Behavioral error: the behavior defined by the protocol specification leads to an 
error like reading stale data, coherency paradox or deadlock. 

2. Origin of the issue detection: an issue can be found: by modeling (during the 
manual analysis of the protocol in order to model it); or by verification (by running 
the verification). 

Table 3 shows cost, issue count (with their classification), along with the total CPU 
time consumed. This last figure is given as a hint and is not a rigorous comparison 
factor, because we have not used the same machines with the same processors in all 
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cases. In FVl, we used 1 machine with small memory size (256 MB); in the other 
cases we had several machines with 1 GB of memory: we were able to launch up to 3 
verifications in parallel. The usage distribution of this CPU time is more meaningful 
and is given by Table 4. 



Table 3. Cost-benefits analysis. Tbe categorization of issues read: A=Ambiguity, 
U=Uncovered, E=Error (coherence paradox or deadlock). Finding origin is M=Modeling or 
V=Verification. So EM means an error found by modeling 



Case 


Cost (p.w) 


CPU (days) 


Benefits (protocol issues raised) 


FV 1 


33 


13 


24 issues 

(1 AM, 9 UM, 2 EM, 1 AV, 4 UV, 7 EV) 


FV2 


17 


42 


15 issues 

(5 AM, 3 UM, 4 EM, 3 EV) 


FV3 


7 


13 


9 issues 

(1 AM, 1 UM, 2 UV, 5 EV) 


FV4 


6 


46 


No issue raised 



FVl is the most costly one and also the one that raised the biggest number of 
issues, half of them by modeling. This is due to the following reasons: it is our first 
experience with Murcp and the modeling-verification process started at the very 
beginning of the protocol definition, when it was still early thoughts. This explains the 
preponderance of ambiguity and uncovered case issues. Half of the CPU time is 
wasted on verifications that did not complete, because of the small memory size. 

In FV2 case, the protocol definition was mature enough (but not finalized) when 
the formal modeling started. We were already familiar with Munp and a small part of 
the first model could be reused, so productivity increases and benefits are still 
important. Most of the issues are raised by modeling and are either uncovered or 
ambiguity issues. Since in this case we had up to 3 machines with more memory, we 
have tried to make use of it, and verify large configurations (with all kinds of 
transaction, for instance) which ended with state explosion: this explains the 
important CPU time consumed. 

In FV3, the protocol is a fairly important extension of FV2 but with the basic 
transaction handling remaining the same (conflict handling is modified and directories 
distribution is modified). The productivity is further increased, there are more errors 
found by verification than by modeling. In this case, based on previous experience, 
we have found the configuration sizes that are manageable without state explosion. 
So, we have not tried to check larger ones, but instead, we have tried several 
combinations of up to 3 nodes in the system distributed over 2 modules. This explains 
that in this case the verification that ended with state explosion are not dominant. 

The last case FV4 is a non-significant extension of FV3 from protocol viewpoint: 
the important modifications are at the routing level and increasing the number of 
supported modules, while we focus on cache coherence protocol. So, to follow this 
architecture extension, we tried to verify larger model configurations (up to 3 
modules) to check new concurrency cases: this naturally increased again the effort 
spent on launching verifications that ended with state explosion. However, significant 
configurations were successfully verified and, as expected, no new issue was 
detected, increasing confidence in the protocol definition correctness. 
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Table 4. CPU time distribution. % of CPU time consumed in verifications that detected 
protocol issues, model bugs, were error-free (terminated with “no error” message), ran out of 
memory. These are rounded figures: 0% = 0, ~0% = a non-null negligible percentage 



Case 


Protocol Issues 


Model bugs 


Error-free 


State explosion 


FV 1 


~0% 


3% 


46% 


51% 


FV2 


~0% 


1% 


30% 


69% 


FV3 


7% 


7% 


71% 


15% 


FV4 


0% 


1% 


38% 


61% 



Protocol issues found by verification are usually detected very quickly, since 
generally it happens on the first models and state graph exploration stops as soon as it 
detects an error. The time range for finding an error is between less than 1 minute and 
a few hours. The time consumed on debugging is not very significant either. 

Finally, this approach was very fruitful and cost-effective, since it helped finding 
hard-to-simulate bugs, generally involving tricky conflict cases, in the early 
development stages. Moreover, these are protocol specification errors, not 
implementation errors, which are much more costly to detect in later development 
stages. 

6 Conclusion 

A distributed directory-based cache coherence protocol is a complex system to 
design, where the conflict resolution rules are a key issue, difficult to apprehend, 
because of concurrency and race conditions. Therefore, it is an outstanding domain of 
application of formal techniques, which provide rigorous analysis and verification 
methods. We have applied formal verification to FAME cache coherence protocol, 
aiming at finding protocol errors with abstracted simplified models. 

Actually, even abstracted and simplified models of such a protocol, which focus on 
these coherence aspects, produce huge state spaces. Due to the Munp reduction 
techniques (symmetry, hash-compaction), specification style and explicit state 
enumeration technique, this obstacle is overcome: the errors found by verification are 
detected very quickly at the beginning of the incremental modeling-verification 
process and are not impacted by state explosion that comes later. Error traces are 
minimal and exhibit a scenario explaining the error origin. 

The experiments show that verifying an abstracted model is sufficient to find 
important protocol bugs: these are most of the time very hard-to-simulate errors that 
involve intricate conflict situations. 

Besides, even if state-of-the-art tools were able to handle larger models, we think 
that building a complete protocol model instead of an abstracted protocol model 
would not be cost-effective in the beginning of the life-cycle of the development. 

A simplified abstracted model is easier to build than a complete model and allows 
mastering more quickly the protocol specification complexity: then in the early phases 
of the development process, it helps in finding issues and improves the understanding 
of the system, as it is shown by the issues found by modeling, which are most of the 
time protocol specification “holes”. 
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The method of protoeol verifieation aimed at finding bugs and inereasing 
eonfidenee in protoeol speeifieation eorreetness proved to be an effieient protoeol 
design aid. The benefits of this approaeh are to deteet protoeol speeifieation errors not 
implementation ones, and to do it in the early development phases. Sinee the first 
experiment on FAME, it was eonsidered fruitful and it was earried on to next 
versions; now it is a well-established praetiee in our protoeol development proeess. 
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Abstract. Witnesses and counterexamples produced by model checkers 
provide a very useful source of diagnostic information. They are usually 
returned in the form of a single computation path along the model of the 
system. However, a single computation path is not enough to explain all 
reasons of a validity or a failure. Our work in this area is motivated by the 
application of action-based model checking algorithms to the test case 
generation for models formally specified with a CCS-like process algebra. 
There, only linear and finite witnesses and counterexamples are useful 
and for the given formula and model an efficient representation of the set 
of witnesses (counterexamples) explaining all reasons of validity (failure) 
is needed. This paper identihes a fragment of action computation tree 
logic (ACTL) that can be handled in this way. Moreover, a suitable form 
of witnesses and counterexamples is proposed and witness and counterex- 
ample automata are introduced, which are finite automata recognizing 
them. An algorithm for generating such automata is given. 



1 Introduction 

Witnesses that show why a formula is satisfied and (more often) counterexam- 
ples that show why it is not satisfied over a model have been used as useful 
diagnostic information since the first applications of model checking technology. 
They are usually returned by model checkers in the form of a computation path. 
However, only for certain kinds of formulae a computation path is able to ex- 
plain completely the reason of satisfaction or missed satisfaction. Only recently, 
a greater interest was raised on the study of the relations between the formulae 
and their counterexamples, on one side looking for richer forms, such as tree-like 
counterexamples [4] or proof-like counterexamples [10], on the other side estab- 
lishing the subsets of the logics whose formulae guarantee linear computation 
paths as counterexamples which completely explain the failure [1, 12]. 

Our work in this field has been motivated by another trend that has con- 
solidated in the recent years, that is the usage of counterexamples as an help 
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to generate test cases [6, 7, 8, 11, 14, 15]. When testing or simulation does not 
reach an adequate level of coverage (defined by some code coverage metrics, such 
as statement coverage and branch coverage) new test cases have to be defined, 
but the process of manually producing test cases for ’’corner-case” scenarios is 
time consuming and error prone. Model checking and counterexamples can help: 
if we have a model of the system, and we model-check on it a formula expressing 
’’there is no uncovered point”, a counterexample returns a computation path 
with enough information to generate the proper test case. In [7] it is shown that 
in the adoption of this principle with a “conquer and divide” approach in order 
to attack the typical state space explosion problem, a more effective option is 
to have the model checker generating not a single counterexample, but all the 
counterexamples for the given formula. We refer to [7] for more details, while 
here we focus on the problem of the efficient representation and generation of 
the set of counterexamples of a given formula. 

Action computation tree logic (ACTL^) [13] is an action-based version of the 
branching time temporal logic CTL [3]. ACTL is suitable to express properties 
of reactive systems whose behaviour is characterized by the actions they perform 
and whose semantics is defined by means of LTS’s. ACTL is adequate with re- 
spect to strong bisimulation equivalence, this means that if p ~ g, then p and q 
satisfy the same set of ACTL formulae. To define ACTL an auxiliary logic of 
actions is introduced. We limit our study to a subset of ACTL that guarantees 
linear witnesses and counterexamples; we address both witnesses and counterex- 
amples, since one can switch between them using negated formulae. Moreover, 
we observe that for the purpose of practical applications (e.g. test case discov- 
ery) only finite linear witnesses and counterexamples are interesting. Further, 
we prove that the set of the desired finite linear witnesses and finite linear coun- 
terexamples forms a regular language and therefore they can be represented as 
automata, that will be called witness automaton and counterexample automaton, 
respectively. 

Formal definitions are given in Section 2. In Section 3, we introduce a viable 
classes of witnesses and counterexamples for application in the field of test case 
generation and define witness and counterexample automata, such that the sets 
of witnesses and counterexamples recognized by them form such a viable class. 
In Section 4 an algorithm to generate witness and counterexample automata is 
reported and comprehensively explained on examples. Section 5 discusses com- 
plexity, implementation, and several directions of possible extension of our work. 
In Appendix, we show some additional examples of generated automata. 

2 Definitions 

Definition 1. {Labelled transition system) 

A labelled transition system (LTS) is a quadruple Ai = {S, Act, D, sq), where S 

^ The acronym ACTL is also used to denote the universal fragment of the CTL, 
whose original name used in [2] was VCTL, later its name has changed for easiness 
of writing, but generating a conflict with the already used name for Action CTL. 
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is a set of states, Act is a set of observable actions (an unobservable action r is 
not in Act), D C S x Act U {r} x S' is the transition relation, and sq G S is the 
initial state. 

For AC Act, we let Da{s) denote the set of successors of the state s reachable 
by an action from the set A. Moreover, we let D\{s) denote Dau{t}{s)- If tt is 
a computation path in an LTS, then 7r(0) is the first state on tt and 7t(i+1) is 
the state on the path tt immediately after the state 7r(i). 

Definition 2. {Action formulae) 

The syntax of action formulae over Act is defined by the following grammar 
where x,x^ range over action formulae, and a G Act: 

X ::= a | ^X I X A X 

The satisfaction of an action formula x by ^tn action a, a \= is inductively 
defined as follows: 

a \= b iff a = 6; 

a\=^X iff a ^ X; 

ahxAx'iffahx and a |= x' 

We write false for a A ~^a, where a is some arbitrarily chosen action, and 
true stands for ^false. Moreover, we will write x^x^ lor ^(^xA^xO- action 
formula permits the expression of constraints on the actions that can be observed 
(along a path or after next step); for instance, aV b says that the only possible 
observations are a or b, while true stands for ’’all actions are allowed” and false 
for ”no actions can be observed”, that is only silent actions can be performed. 

Definition 3. (Action computation tree logic) 

The syntax of ACTL is defined by the following grammar, where X) x' range 
over action formulae, 3, V are path quantifiers, and X, U are next and until 
operators, respectively: 

(fi ::= true | | A (p | dy | Vy 

1 x^x' ^ 

Let k(x) = {a | a |= x}- Being interpreted over an LTS M = {S,Act,D,SQ) 
with total transition relation the satisfaction of a state formula y: by a state s, 
s \=M and path formula y by a path tt, tt \=m y, is inductively defined by: 

s \=M true always; 

s \=M iff s P', 

s \=M p /\ p' iS s \=M P and s \=m p'; 

s \=M 3 7 iff there exists a path tt such that 7t(0) = s and n \—x 4 y; 

s \=M V 7 iff for all paths tt such that 7t(0) = s, tt \—x 4 y; 

TT \=M P iff there exists 7 t( 1) such that ■Tr(l) G (■Tr(O)) and rr)!) \=x 4 P', 

TT \=M Xt p iff there exists 7 t( 1) such that rr)!) G Dp} (7 t( 0)) and 7 t(1) \=m P', 
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7r \=M ^ xU iff there exists i>0 such that 7r(i) \=m ^p' , 

and for all 0 < j < i-1 : 7r(j) \=m P and 7r(j + l) G (rrO')); 

7T \=M iff there exists i> 1 such that 

■n{G)\=M‘P, TT(i)\=Mp', 7r(i) G Dk(^/) ( 7r(i— 1)), and for all 1: 

ttO') hM V and 7r(j) G -Cr(^)(7r(j-1)). 

We write false for ^true and ip\/ if' for ~^{-^f A ^f'). When the transition 
system is clear from the context, we write s \= f instead of s \=m If « |= X 
and t \= f then transition (s, a, t) is called a (x, i^)-transition. Transitions, which 
are not (x, </5)-transitions, are called ^(x> v?)-transitions. If s |= we say that f 
holds in state s. An ACTL formula f is satisfied over a given LTS Af (Ad |= f) 
iff f holds in the initial state of Ad . The satisfaction of ACTL formulae over LTS 
Ad/ having a not total transition relation (i.e. Ad/ contains deadlocked states) 
is given as follows: let f be an ACTL formula and Ad ^ be an LTS obtained from 
Ad/ by adding r-loops in all its deadlocked-states; then Ad/ \= f ii M'j ^ f. 

Several useful modalities can be defined, starting from the basic ones: 

— 3F f for 3(true/j.ygU(/>), and VF f for V(true/j.^gU/5) {eventually operators); 

~ <x> f ioT 3Xj^ f, and [x] f for ^3X^ -^f (Hennessy-Milner modalities^); 

— 3G f for ^VF ^f, and VG f for ^3F ~^f {always operators). 

Given a model Ad and a formula f such that M. \= f (Ad ^ </i), a witness 
(counterexample) is a structure 72,, in relation with Ad, that completely shows 
one of the possible reasons why M. \= f (Ad f). A reason why Ai \= f will 
be called a reason of validity and a reason why A4 ^ f will be called a reason 
of failure. The type of the relation between TZ and Ad determines the nature of 
the witnesses and countererexamples. Linear witnesses and counterexamples are 
finite or infinite computation paths over Ad. More complex forms of witnesses 
and counterexamples [4, 10] are defined as non-linear structures related to the 
original model Ad. In our approach. Ad is an LTS and f is an ACTL formula. 
Further, we formally define linear witnesses and counterexamples for an ACTL 
formula over an LTS; richer forms of witnesses and counterexamples are not 
directly addressed in this paper. 

Definition 4. {Linear witness and counterexample for ACTL formula over LTS) 
Given an LTS Ad and an ACTL formula f such that Ai\= f (Ad ^ f), a linear 
witness (counterexample) for f over Ad is a sequence of actions that completely 
shows one of the possible reasons why Ad |= (/? (Ad ^ f). 

3 Witness and Counterexample Automata 

In [4], it has been recognized that for practical end-applications not all witnesses 
and counterexamples are usable. For example, the whole LTS is always a witness 
or a counterexample. Following the interpretation of [4] , a viable class of witnesses 
(counterexamples) V meets the criteria of: 

^ In [13], < X > V [x] defined and used instead as the weak version of the 

diamond and box operators of Hennessy-Milner logic. 
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— Completeness. Every reason of validity (failure), which is important for 
end-application, can be explained by a witness (counterexample) in V. 

— Intelligibility. Witnesses (counterexamples) in V are specific enough to suit 
the end-application (e.g. simple enough to be analysed by engineers). 

— Effectiveness. There exist effective algorithms for generating and manipu- 
lating witnesses (counterexamples) in V. 

Note, that these criteria need to be adapted to the end-application. The test 
case generation approach in [7] is based on finite linear counterexamples, which 
are no longer than necessary, i.e. they contain only transitions, which contribute 
to the explanation of a particular reason of failure. Thus, we formally define the 
viability criteria in the field of test case generation as follows. 

Definition 5. ( Viability criteria in the field of test case generation) 

The class of witnesses (counterexamples) V is a viable class for application in 
the field of test case generation iff for the given ACTL formula (p and LTS Ad 
there exists a suitable witness (counterexample) in V, which 

1. explains all reasons of validity (failure) of (p over Ad explainable by finite 
linear witnesses (counterexamples), 

2. is as small as possible, and 

3. is computable by an effective algorithm. 

Let Ad be an LTS. In general, all reasons of validity (failure) of an arbi- 
trary ACTL formula p over Ad cannot be explained with finite linear witnesses 
(counterexamples) . We avoid the problem of completeness by restricting the ap- 
proach to the ACTL formulae which guarantee linearity and finiteness, i.e. for 
which all reasons of validity (failure) can be explained with finite linear witnesses 
(counterexamples) over all models. 

Theorem 1. ACTL formulae of kind p (ip) as given by the grammar, when sat- 
isfied (not satisfied) over an LTS, guarantee linear witnesses (counterexamples): 

p ::= true | -^tp \ p\f p \ 3(true p) \ 3(true p) \ 3X;,^, p \ 3X.^ P 
Ip ::= false | ^p | '0 A "0 | V(0 true) | V(0 true) | VXp^. ip \ VX,- ip 

Proof. Theorem 1 can be proved by induction on subformulae. The basic cases 
are formulae true and false, and every path contains sufficient information for 
explaining them. Due to a short space, we give a proof only for ACTL formulae 
of kind 3(true ^\5^p). Let Ad be an LTS, 7 = true x^x' ‘f ~ ^7^ M \= p. 
According to Definition 3, the reason of validity is the existence of paths starting 
in the initial state of Ad, which satisfy path formula 7. Thus, a witness is a proof 
that a particular path tt satisfies path formula 7. If the path tt itself contains 
sufficient information to show why tt ^ 7 then tt is a linear witness. According 
to Definition 3 again, for each tt |= 7 there exists * > 1 such that -nii) ^ p' and 
7r(i) e L0(;^/)(7r(i — 1)), and for all 0 < j<i—l: 7r(j) G D^^^^(7r(j — 1)). Now, the 
path from the first state until state 7r(i) needs no additional explanation. We 
must only show 7r(i) |= p'. But, due to the induction hypothesis, subformula p' 
guarantees linear witnesses and therefore the suffix of the path from state Tr(i) 
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contains sufficient information for explaining 7r(t) |= (/?'. Hence, any path tt such 
that TT ^ 7 is a linear witness. 

Some formulae with derived modalities can also be used in the presented 
approach. Indeed, formulae 3F (p and <x> guarantee linear witnesses, while 
formulae VG if: and [x]' 4 ’ guarantee linear counterexamples. 

Theorem 1 assures linearity but not finiteness. In fact, all ACTL formulae 
of the given sublogic, except those of kind true), guarantee also finite- 

ness. Therefore, we exclude formulae of this kind from this approach. We also 
exclude ACTL formulae of kind V(f/' true), as they always hold and have no 
linear witnesses and no linear counterexamples. For all other kind of formuale 
of the given sublogic and an LTS M with total transition relation, we define in 
a constructive way V- witnesses and V-counterexamples, respectively. 
Definition 6. (V -witness and V -counterexample) 

(a) A V-witness for ACTL formula true is a path consisting of only one state 
and no transitions. 

(b) A path 7T in A4 is a V-witness for ACTL formula p = -if/' iff tt is a V-counter- 
example for ACTL formula ip. 

(c) A path 7T in A4 is a V-witness for ACTL formula (/? = V (/?2 iff tt is a V- 
witness for pi ((^ 2 ) and no proper prefix of tt is a V-witness for ip2 (resp. 
Vi)- 

(d) A path 7T in A4 is a V-witness for ACTL formula (p = 3(true yJJ p') iff there 

exists i > 0 such that suffix of tt starting in 7r(i) is a V-witness for ACTL 
formula p' ^ and for all 0 < j < i— 1: Tr(j-l-l) G D^^^^(7r(j)) and 7r(j) p' . 

(e) A path tt in A4 is a V-witness for ACTL formula p = 3(truep^U;^/ p') iff 
there exists i > 1 such that n{i) G D^(P^/)(7r(z — 1)) and suffix of tt starting 
in 7t(z) is a V-witness for ACTL formula p', and for all 0 < j < i— 1: 

-1)), and also 7r(j) ^ D„(^/)(7r(j-l)) or 7r(j) <p'- 

(f) A path TT in A4 is a V-witness for ACTL formula p = 3X^^ p' iff 7r(l) G 
^k(x)('^W) suffix of TT starting in 7 t( 1) is a V-witness for ACTL formula 

v'- 

(g) A path TT in AI is a V-witness for ACTL formula p = 3Xt- p' iff 7r(l) G 
I?{.r}(7i'(0)) and suffix of tt starting in 7r(l) is a V-witness for ACTL formula 

v'- 

(h) A V-counterexample for ACTL formula false is a path consisting of only one 
state and no transitions. 

(i) A path TT in A4 is a V-counterexample for ACTL formula f/' = ~'‘P iff tJ" is 
a V-witness for ACTL formula p. 

(j) A path TT in A4 is a V-counterexample for ACTL formula tp = ipi A tp 2 
iff TT is a V-counterexample for ipi {1P2) and no proper prefix of tt is a V- 
counterexample for 'tp2 (resp. tpi). 

(k) A path TT in AI is a V-counterexample for ACTL formula f/' = '^'^x iff 
7t(1) ^ iA(^)(7r(0)) and tt contains only two states, or 7t(1) G Dk(p^)(7t(0)) 
and suffix of tt starting in 7r(l) is a V-counterexample for ACTL formula p' . 
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(1) A path 7T in is a V-counterexample for ACTL formula ij) = VX,- ip' iff 
7 t(1) ^ D{t-}(7t( 0)) and tt contains only two states, or 7r(l) G £){^}(7r(0)) and 
suffix of 7T starting in 7r(l) is a V-counterexample for ACTL formula (/?'. 

It is straightforward to show that all V-witnesses (V-counterexamples) are 
finite linear witnesses (counterexamples) . The following theorem shows that they 
are suitable for our approach. 

Theorem 2. Let tt be a finite linear witness (counterexample) explaining a 
reason of validity (failure) of an ACTL formula Lp {pi) over an LTS Ad. Then, 
there exists V-witness (V-counterexample), which shows that M. \= tp {Ai ^ ip). 

Proof. We claim, that the smallest (not necessary proper and therefore always 
existing) prefix of tt, which shows that Ad |= (/? (Ad ^ ip) is a V-witness (V- 
counterexample) . To show this, we observe finite linear witnesses (counterexam- 
ples), which are not V-witnesses (V-counterexamples) and prove, that a proper 
prefix of them exists, which explain Ai \= p (Ad ^ ip). We omit the details of 
the proof due to the lack of space. 

Further, we show that we can characterize not only a single V-witness and 
V-counterexample, but also the set of all the possible ones. Actually, the number 
of the possible V-witnesses and V-counterexamples may be infinite and we are 
interested to a finite representation of them all. 

Theorem 3. Let Ad be a finite state LTS and p {ip) an ACTL formula such that 
Ad ^ (Ad ^ Ip). Then, there exists a finite-state automaton which recognizes 
all V-witnesses (V-counterexamples) for formula p {ip) over Ad. 

Proof. In order to check whether a path is a V-witness (V-counterexample), we 
just need to see whether it is a path over Ad and if it has the form given in Defi- 
nition 6. Since the characterizations given in Definition 6 are given with a single 
right recursion, they can be expressed as a regular grammar. The language of 
V-witnesses (V-counterexamples) is the intersection of the regular language rec- 
ognized by this grammar and the regular language of the finite paths over Ad. 
Hence, it is a regular language and can be recognized by a finite state automaton. 
Definition 7. ( Witness and counterexample automata) 

A witness (counterexample) automaton for an LTS Ad and an ACTL formula 
p is an automaton which recognizes the language of all V-witnesses (V-counter- 
examples) of p over Ad. 

Now, only an effective algorithm for generation of witness and counterexam- 
ple automata is missing to fit the viability criteria in Definition 5. 

4 Implementation 

We present here an elegant recursive algorithm that, given a LTS and a for- 
mula p from the subset of ACTL given in Theorem 1, generates the witness 
or counterexample automaton WCA for the formula p over the given LTS. If 
the formula p holds in the initial state of LTS, the generated WCA is a wit- 
ness automaton, otherwise, it is a counterexample automaton. The algorithm is 
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WCAgenerator (LTS, (/?) { 

for all subformiilae ip' of formula p { 

create subset of LTS states Sp in which formula p' holds; 
create empty relation Rp] 

} 

let s be the initial state of LTS; 
create empty automaton WCA; 
create the initial state t in WCA; 
if (s G Sip) generate (LTS, p, s, t, witness); 
else generate (LTS, p, s, t, counterexample); 

} 

generate (LTS, p, s, t, type) { 
if (type == null) { 

add t to the set of WCA final states; 

} else { 

add the pair (t, s) to Rp ; 

if (type == witness) WAgen (LTS, p, s, t); 

if (type == counterexample) CAgen (LTS, p, s, t); 

} 

} 

conbuild (LTS, p, a, s', t, type) { 

if ((type == null) || (there is no state related to state s' in Rp)) { 
create a new state t' in WCA; 
if not exists, add the transition {t, a, t') to WCA; 
generate (LTS, p, s' , t' , type); 

} else { 

let t' be a state in WCA related to state s' in Rp, 
if not exists, add the transition (t, a, t') to WCA; 

} 

} 

Fig. 1. Main function and two auxiliary functions of the algorithm 



a direct implementation of the definitions of V-witnesses and V-counterexamples 
and it is given in a C-like pseudocode. It consists of the main function WCA- 
generator, two auxiliary functions generate and conbuild (Fig. 1), and functions 
processing ACTL formulae (Fig. 2, 3). For the purpose of further work, the part 
for generation of counterexample automata is extended with formulae of type 
V('i/' x^x true). For them, V-counterexamples have not been defined. Computa- 
tion paths recognized by the obtained automaton for this kind of ACTL formulae 
explain only those reasons of failure which can be explained with finite linear 
counterexamples. Due to the lack of space, we are not able to discuss details of 
this feature. 
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WAgen (LTS, (p, s, t) { 
case if == true: 

generate (LTS, p, s, t, null); 
break; 

case (f == ^ip': 

generate (LTS, p', s, t, counterexample); 
break; 

case p == Pi V p 2 '- 

if (s G generate (LTS, p\, s, t, witness); 
if (s G S^p 2 ) generate (LTS, p 2 , s, t, witness); 
break; 

case p == 3X^ p': 

WAbuild (LTS, p, s, t, false, false, x> y’Oi 
break; 

case p == 3X,- p': 

if (s is a deadlocked state) generate (LTS, p' , s, t, witness); 

else WAbuild (LTS, p, s, t, false, false, r, p')] 
break; 

case p == 3(true;^U p'): 

if (s G S^pl) generate (LTS, p', s, t, witness); 

WAbuild (LTS, p, s, t, (x V t), true, (x V r), p'); 
break; 

case p == 3(true;^Up^' p'): 

WAbuild (LTS, p, s, t, (x Vr), true, x', v')', 
break; 

} 

WAbuild (LTS, p, s, t, Xi, X 2 , V 2 ) { 

let be the set of ^(x 2 , < 7 ’ 2 )-trans. from s which are (xi, V5i)-trans.; 
forall transitions (s, a, s') G <5i { 

if (s' G Sip) conbuild (LTS, p, a, s', t, witness); 

} 

let 62 be the set of (x 2 , V52)-transitions from s; 
forall transitions (s, a, s') G <52 { 

conbuild (LTS, p 2 , a, s', t, witness); 

} 

} 

Fig. 2. The part of the algorithm, which generates witness automaton 



The algorithm proceeds by visiting a portion of the state space of LTS. The 
visit is guided by the structural analysis of the formula itself, hence it is termi- 
nated when the leaves of the formula are reached. In ACTL, leaves can only be 
the formula true or the formula false. LTS is unfolded if a sequence of subformulae 
of p matches with a loop in it. The visit is implemented by a depth-first search by 
recursion, and hence it has to be remembered which states of LTS have already 
been visited with a particular subformula of p. Unfortunately, the resulting au- 
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CAgen (LTS, ip, s, t) { 
case ip == false: 

generate (LTS, ip^ s, t, null); 
break; 

case ip == ~^ip': 

generate (LTS, ip', s, t, witness); 
break; 

case ip == ipi A ip2'- 

if (s ^ generate (LTS, ipi, s, t, counterexample); 

if (s ^ generate (LTS, ip2, s, t, counterexample); 

break; 

case ip == VX^ ip'\ 

if (s is a deadlocked state) generate (LTS, ip, s, t, null); 

else CAbuild (LTS, ip, s, t, false, false, x, ip')-, 
break; 

case ip == VX.T ip': 

if (s is a deadlocked state) generate (LTS, ip', s, t, counterexample); 

else CAbuild (LTS, ip, s, t, false, false, t, ip')-, 
break; 

case ip == V((/?' x^x' true): 

if (s is a deadlocked state) generate (LTS, ip, s, t, null); 
if (s ^ Sipi) generate (LTS, ip', s, t, counterexample); 

CAbuild (LTS, ip, s, t, (x Vr), ip', x', true); 
break; 

} 

CAbuild (LTS, ip, s, t, xi, ipi, X2, ^^2) { 

let be the set of ^(x2, <A2)-trans. from s which are (xi, <Ai)“trans.; 
forall transitions (s, a, s') € < 5 i do { 

if {s' ^ Sip) conbuild (LTS, ip, a, s', t, counterexample); 

} 

let 82 be the set of ^(x2, ‘A2)-trans. from s which are ^(xi, <Ai)“trans.; 
forall transitions (s, a, s') € 82 { 

{a Y= xi 8\ CL X2) conbuild (LTS, ip, a, s', t, null); 
if (a ^ xi) conbuild (LTS, ipi, a, s', t, counterexample); 
if (a ^ X2) conbuild (LTS, ip2, a, s', t, counterexample); 

} 

} 

Fig. 3. The part of the algorithm, which generates counterexample automaton 



tomaton can be slightly incorrect. It may recognize some paths, which are finite 
linear witnesses (counterexamples) but not V-witnesses (V-counterexamples). 
However, it can always be minimized to fit Definition 7 . We will discuss about 
this in the next section. 

The algorithm is further explained in details using a simple LTS and two 
simple ACTL formulae (Fig. 4 ). It starts in function WCAgenerator. The first 
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(a) The model: S = a.S + b.b.nil 




(b) Witness automaton for 3Xa 3Xo true 




(c) Witness automaton for 3F 3Xb true 



Fig. 4. Two examples of generated witness automata. For the second ACTL formula, 
the resulting automaton must be properly minimized to obtain the correct witness 
automaton indicated by a dashed polygon 



action is actually a call to a model checker, which computes S and initializes R 
for all subformulae of (p. S contains for each subformula the subset of states that 
satisfy the subformula. Thus, the algorithm takes for granted the information 
about validity of the subformulae on each state, i? is a relation implemented 
as a set of pairs, where for each state of the LTS visited with a particular 
subformula the related state in WCA is stored. Variables WCA, S, and R are 
global, all others are local. Here is a program trace for the example in Fig. 4b. 

ACTL model checking on S 
EXfa}- EX{a} true ==> TRUE 

@@ WCAgenerator : created empty witness automaton WClS 
@@ WCAgenerator: created initial state wcl 

@@ generate: starting formula ‘EXfa}- EX{a} true’ for (s=sl, t=wcl) 

@0 generate: added pair (wcl, si) to R for the current formula 
@0 WAbuild: chosen transition sl-a->sl from delta2 
@0 conbuild: created state wc2, created transition wcl-a->wc2 
@@ generate: starting formula ‘EX-faf true’ for (s=sl, t=wc2) 

@@ generate: added pair (wc2,sl) to R for the current formula 
@@ WAbuild: chosen transition sl-a->sl from delta2 
@0 conbuild: created state wc3, created transition wc2-a->wc3 
@0 generate: starting formula ‘true’ for (s=sl, t=wc3) 

@@ generate: added pair (wc3,sl) to R for the current formula 

@@ generate: state wc3 marked as final 

@@ Witness automaton has been constructed. 
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After an ACTL model checker determines that formula 3Xo 3Xo true holds 
in the initial state si of S, a generation of the witness automaton is started. 
A new automaton WClS and its initial state wcl are created. Function generate 
makes initial states of S and WClS to be related for the formula 3 Xq 3Xa true. 
Then, function WAgen is started. The outermost operator is 3Xa and therefore 
function WAbuild is called with parameters xi = false, ipi = false, X 2 = a, and 
Lp 2 = 3Xo true. Set (5i is empty, because there is no (xi, V5i)-transition. Set 82 
contains only the transition (si, a, si). State si has not been visited with 
formula 3Xa true, yet, and therefore there is no state in WClS related to it. 
Function conhuild creates a new state wc2 and the transition (wcl, a, wc2) in 
WClS. Then, function generate is recursively called for the formula 3Xo true. In 
this call, subformula ip 2 = true. Again, set is empty, while set 82 contains 
the transition (si, a, si). Because state si has not been visited with formula 
true, yet, function conbuild creates a new state wc3 and transition (wc2, a, wc3). 
Further, state wc3 is marked as final and the recursive calls end. 

The usage of relation R is better shown on a program trace for ACTL formula 
3F3Xf,true. Actually, this is an abbreviation of formula 3(true^j.ygU 3X;,true). 

ACTL model checking on S 
EF EXfb}- true ==> TRUE 

@@ WCAgenerator : created empty witness automaton WC2S 
@0 WCAgenerator: created initial state wcl 

@@ generate: starting formula ‘EF EXfb}- true’ for (s=sl, t=wcl) 

@@ generate: added pair (wcl, si) to R for the current formula 
@@ generate: starting formula ‘EXfb}- true’ for (s=sl, t=wcl) 

@0 generate: added pair (wcl, si) to R for the current formula 
@0 WAbuild: chosen transition sl-b->s2 from delta2 
@0 conbuild: created state wc2, created transition wcl-b->wc2 
@@ generate: starting formula ‘true’ for (s=s2, t=wc2) 

@@ generate: added pair (wc2,s2) to R for the current formula 

@@ generate: state wc2 marked as final 

@0 WAbuild: chosen transition sl-b->s2 from delta2 
@0 conbuild: created state wc3, created transition wcl-b->wc3 
@0 generate: starting formula ‘EXfb}- true’ for (s=s2, t=wc3) 

@@ generate: added pair (wc3,s2) to R for the current formula 
@0 WAbuild: chosen transition s2-b->s3 from delta2 
@@ conbuild: created state wc4, created transition wc3-b->wc4 
@@ generate: starting formula ‘true’ for (s=s3, t=wc4) 

@0 generate: added pair (wc4,s3) to R for the current formula 

@@ generate: state wc4 marked as final 

@0 WAbuild: chosen transition sl-a->sl from delta2 
@@ conbuild: created transition wcl-a->wcl 
@@ Witness automaton has been constructed. 

Because subformula 3X{, true holds in the initial state of S, first a V-witness 
for it is generated. State wc2 and transition (wcl, b, wc2) are created. Then, 
function WAgen continues and calls function WAbuild with parameters xi = true, 
V 3 i=true, X2 = true, and (/?2 = 3X;, true. Set is empty, while set 82 contains 
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transitions (si, a, si) and (si, b, s2). The transition with action b is chosen 
first. Formula 3X{, true has been already visited in state si, but not in state 
s2. Therefore, state wc3 and transition (wcl, b, wc3) are created. Afterwards, 
the algorithm continues in the state s2. State wc4 and transition (wc3, b, wc4) 
are created. Because subformula true has been reached, state wc4 is marked as 
final and the path is finished. Now, function WAbuild must also process tran- 
sition (si, a, si) from 62- State si has been visited with formula 3F 3X;, true 
before, thus a new state is not created. State si is related to state wcl in rela- 
tion ax true> therefore transition (wcl, a, wcl) is created without further 
recursive calls. 

5 Discussion 

The algorithm for witness and counterexample automata generation basically 
works by following the given LTS and using unfolding when necessary, with an 
unfolding depth of at most the length of the formula. Therefore, the complexity 
is not higher than the size of the LTS (states and transitions) times the length of 
the formula. This is exactly the same complexity of an explicit model checking 
algorithm which has to be employed to compute the labeling of the LTS. 

We have implemented the algorithm as an extension of a BDD-based ACTL 
model checker. Although LTSs are represented by BDDs and BDD-based func- 
tions are used for navigating the LTS, the algorithm indirectly still involves an 
implicit enumeration in functions WAbuild and CAbuild, where transitions are 
chosen from <5i and 62 one by one and then for each next state on the path 
a new recursive call is made. An open question remains whether a more efficient 
symbolic algorithm exists. 

The last example in the previous section and some of the examples given 
in Appendix clearly show that the resulting automata may contain redundancy. 
In fact, there are two different kinds of redundancy. At first, some equal paths 
may be presented more than once. This is not very disturbing and among other 
reasons it appears because the program does not identify two semantic equal 
subformulae as the same one. For example, in the witness automaton generated 
for the ACTL formula (3X^ ip) V (3X^ p), all paths are doubled. The second 
type of redundancy is much more problematic as it leads to the incorrect result. 
It appears due to the fact, that during the generation of the automaton the 
algorithm does not check, whether one of the created paths explaining one reason 
of validity (failure) is a proper prefix of another created paths explaining another 
reason of validity (failure). In such case, only the shorter path is a V-witness (V- 
counterexample) and thus the generated automaton should recognize only the 
shorter one and not both. The ACTL formulae, which are subject to this kind 
of redundancy are all those which contain Boolean operator V or A, explicitely 
or implicitely as, for example, formula 3(truep^U p') and derived formula 3F p. 
To obtain the correct automaton, all extra paths must be later eliminated by 
a proper minimization. 
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A result which is related to our work is the definition of more expressive 
tree-like counterexamples for Kripke Structures and CTL; such counterexamples 
are used as a support to guide a refinement technique [4]. The main difference 
with respect to our approach is that a tree-like counterexample is in its entirety 
a proof that the formula is not satisfied. Our counterexample automaton gives 
instead the set of linear counterexamples, each of which can be taken separately 
as a traditional counterexample. An evolution of tree-like counterexamples is 
represented by proof-like counterexamples [10], used to extract proofs for the non 
satisfiability of a formula over a model. Closer to our approach is the multiple 
counterexamples generation of [5, 9], which generates all the counterexamples 
up to a given length, expressed as a single counterexample trace annotated with 
possible values of binary variables. 

There are some possible directions for further work. We have considered only 
finite witnesses and counterexamples, which are the ones suitable to be used as 
actual test cases (see [7]). Having more rich notions of acceptance than linear 
languages could provide the possibility of characterizing sets of more informative 
witnesses and counterexamples. In order to deal with infinite counterexamples 
and witnesses the same approach can be followed, for example, using Biichi au- 
tomata for recognizing a language of infinite words. In this way, if the transition 
relation is total and if witnesses and counterexamples are extended to become 
infinite paths, our work becomes adequate to the work presented for CTL in [1]. 

An interesting extension of the given algorithm would be a generation of 
non-linear forms of witnesses and counterexamples. The core of the algorithm 
are functions WAbuild and CAbuild. We implemented them in a more general 
form w.r.t. what needed in this approach. For example, function WAbuild will 
also process ACTL formula '^ 2 ), where parameter ipi is not just a sim- 

ple formula true or false, although a witness for this formula is not always a linear 
computation path. The algorithm will produce an automaton recognizing linear 
witnesses and the main paths (sometimes referred as backbones) of non-linear 
witnesses. There will be no extra information given about which recognized 
witness completely explains the validity and which one is only a main path of 
a non-linear witness. Such general implementation allows extensions. If param- 
eter ipi is not a simple formula true or false and if an explanation of validity is 
added to all states on the main path, we get richer non-linear forms of witnesses. 
Thus, the given algorithm can serve also as a basis for generation of tree-like 
witnesses and counterexamples. Note that for the formulae which guarantee lin- 
earity and finiteness of witnesses (counterexamples) the presented witness and 
counterexample automata explain all reasons of validity (failure) over a given 
model and thus they are equivalent to the tree-like witnesses and counterexam- 
ples, respectively. 

6 Conclusions 

We have defined witness and counterexample automata, which are intended to be 
used in the field of test case generation. These automata recognize V-witnesses 
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and V-counterexamples which are finite linear witnesses and counterexamples 
for a given formula over a given LTS. The main result of the paper is the al- 
gorithm for generating witness and counterexample automata for a given LTS 
and a given ACTL formula from a subset of ACTL formulae which guaran- 
tee finite linear witnesses and counterexamples. The algorithm has been imple- 
mented and a stand-alone demo application has been made available online on 
http : //fmt . isti . cnr . it/WCA/. 

It seems reasonable that the given approach works as well with a state based 
formalism (such as Kripke structures) and a state based temporal logic (such 
as CTL). This needs to be verified: the very definition of witnesses, counterex- 
amples, and automata recognizing them is actually highly sensitive to the logic 
used and to the assumptions on the models. 
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Abstract. Symmetry based approaches are known to attack the state space ex- 
plosion problem encountered during the analysis of distributed systems. In an- 
other way, BDD-like encodings enable the management of huge data sets. In this 
paper, we show how to benefit from both approaches automatically. Hence, a quo- 
tient set is built from a coloured Petri net description modeling the system. The 
reachability set is managed under some explicit symbolic operations. Also, data 
representations are managed symbolically based on a recently introduced data 
structure, called Data Decisions Diagrams, that allow flexible definition of appli- 
cation specific operators. Performances yielded by our prototype are reported in 
the paper. 

Keywords: Decision Diagrams, Symbolic Model-checking, Symbolic Reacha- 
bility Graph, Well-Formed Petri Nets, Symmetry Detection 



1 Introduction 

In this paper, we exploit both data symmetries to construct a set of reachable equiv- 
alence classes of states, and a symbolic coding of these classes and of the transition 
relation using a BDD-like representation. The construction of this reachability set is the 
basis for model-checking, verification of safety constraints, deadlock detection, etc. 

Roughly speaking, model checking of symmetrical systems exploits the fact that 
many synchronization and communication protocols, involving parallel composition 
of n processes differing only by their identity, often exhibit considerable symmetries. 
This can be viewed as a redundancy of information in the state graph, as states identical 
up to a permutation can be aggregated into equivalence classes, yielding a possibly 
exponentially smaller quotient state space. The efficiency of this type of approach is 
demonstrated by tools like GreatSPN, SMC, Mur-(|), which offer mechanisms to define 
the symmetries allowed by the model (for instance the Mur-(|) scalarset). 

The core of the problem consists in determining whether two states are equiva- 
lent; one approach found in literature is to define a canonization operation that yields 
a unique representative for each equivalence class, thus only representatives need to be 
stored. However it has been proved that the BDD coding the orbit relation required to 
find a unique representative of an equivalence class would need an exponential number 
of nodes [3]. The approach used here is based on the work of [1] which uses dedicated 
data-structures to represent equivalence classes, termed Symbolic Markings (SM), in- 
stead of concrete states designated as representatives. In practice, such a direct coding 
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of the equivalence classes can speed up the computation of the quotient graph. In the 
literature, one can find other codings which use close concepts [8]. 

Furthermore, the symmetries exploited to construct an SM are computed automat- 
ically through a structural exploration of a model. This procedure uses the algorithm 
described in [10] and assumes a modeling in a coloured Petri net to produce a Well- 
Formed net. It is fully automatic and has a polynomial complexity over the size of the 
model. The symbolic reachability set (SRS) is then built by means of a symbolic firing 
rule, that does not require the actual concrete states to be explored. The steps required 
for this construction are: from a set of SM, a symbolic firing rule is applied yielding 
a new set of (intermediate) symbolic states. These last SMs are then canonized yielding 
a set of canonical representatives, which can be compared to already obtained canonical 
SMs. 

The challenge we address here is to define these operations on a BDD-like rep- 
resentation, although the structures used to describe equivalence classes of states are 
calculated dynamically, use a priori unbounded integer domains, have a variable do- 
main size according to the dynamically grouped elements, and require quite complex 
data-structures to represent them. We show how the specific dag library called Data De- 
cision Diagrams (DDD), that allows flexible operation definition possibilities through 
inductive homomorphisms, meets our needs. Application of DDD to uncoloured “ex- 
tended Petri nets” [4] has shown their expression power and dynamic capabilities. We 
make full use of available DDD features: variable repeats, variable length vectors, and 
we rely on hierarchical computations to maximize cache hit ratio. 

This paper is organized as follows: section 2 presents a brief overview of DDD 
capabilities and introduces the Well-Formed nets (VWV) formalism; section 3 gives the 
principles used in the coding of a state; section 4 presents the main symbolic firing op- 
eration and section 5 the minimization and canonization procedures; section 6 describes 
the state space construction procedure; finally, section 7 reports the performances of the 
tool implementing this technique on a few classical examples. 

2 Context 

2.1 DDD Basic Concepts and Inductive Homomorphism 

Data Decision Diagrams (DDD) are a data structure for representing finite sets of as- 
signments sequences of the form [x\ := vi) • (x 2 := V 2 ) • • • := v„) where Xi are vari- 

ables and V,- are the assigned integer values. When an ordering on the variables is fixed 
and the values are booleans, DDD coincides with the well-known Binary Decision Dia- 
gram. When the ordering on the variables is the only assumption, DDDs correspond to 
the specialized version of the Multi-valued Decision Diagrams representing character- 
istic function of sets [2]. However DDDs assume no variable ordering and, even more, 
the same variable may occur many times in a same assignment sequence. Moreover, 
variables are not assumed to be part of all paths. Therefore, the maximal length of a 
sequence is not fixed, and sequences of different lengths can coexist in a DDD. This 
feature is very useful when dealing with dynamic structures like queues. 

DDDs have three terminals : 1, 0 and T. As usual for decision diagram, 1 -leaves 
stand for accepting terminators and 0-leaves for non-accepting ones. Since there is no 
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assumption on the variable domains, the non-accepted sequences are suppressed from 
the structure. 0 is considered as the default value and is only used to denote the empty set 
of sequence. This characteristic of DDDs is important as it allows the use of variables 
of finite domain with a priori unknown bounds. The T terminal is introduced to resolve 
conflicts introduced by the fact that no variable ordering is required and that a same 
variable can appear several times in a same sequence. 

In the following, X denotes a set of variables, and for any xinX, Dom(x) represents 
the domain of x. 

Definition 1 (Data Decision Diagram). The set ID of DDDs is defined by d &1D if: 

- Je {0,l,T}or 

- d= {x, a) with: 

• X GX 

• a : Dom(x) ^ ID, such that {v G Dom(x) | a(v) 0} is finite. 

We denote x — ^ d, the DDD (x, a) with a{a) = d and for all v a, a(v) = 0. 

As usual, DDDs are encoded as (shared) decision trees. Hence, a DDD of the form 
(x, a) is encoded by a node labeled x and for each v G Dom(x) such that a(v) f 0, there 
is an arc from this node to the root of a(v). By the definition 1, from a node (x, a) there 
can be at most one arc labeled by v € Dom(x) and leading to a(v). This may cause 
conflicts when computing the union (noted +) of two DDDs. Consider for instance d = 
(a— ?-^l) + (a^-^a^-^l) = + a^_^l). We need to compute (b^->l + 

a^-s-l). If a = b, this can be resolved by creating a node of variable a having two arcs 
to the terminal 1 labeled with values 2 and 3. However if a we cannot decide what 
variable the resulting node should bear. The result is therefore undefined, and is noted as 
such by the terminal T. Thus d will evaluate to = a~^T . More formally, T represents 
any set of finite assignment sequences, therefore T is the worst approximation of a finite 
set of assignment sequences. When T does not appear in a DDD d, d represents a unique 
finite set of assignment sequences. Such DDDs are said well-defined. We require that the 
DDDs we manipulate be well-defined, and we will detail in section 3.1 how we ensure 
this property. For a complete definition of DDDs and particulary of their operations, 
please refer to [4]. 

DDDs are equipped with the classical set-theoretic operations. They also offer a 
concatenation operation d\ ■ da which replaces 1 terminals of d\ by d 2 . Applied to well- 
defined DDDs, it corresponds to a cartesian product. In addition, homomorphisms are 
defined to allow flexibility in the definition of application specific operations. 

A basic homomorphism is a mapping O from ID to ID such that 0(0) = 0 and 
0(<7 + d') = 0((f) + 0(c?'),V<7,(f' G ID. The sum and the composition of two homo- 
morphisms are homomorphisms. Some basic homomorphisms are hard-coded. For in- 
stance, the homomorphism d*Id where G ID, * stands for the intersection and Id for 
the identity, allows to select the sequences belonging to d. The homomorphisms d ■ Id 
and Id ■ d permit to left or right concatenate sequences. We widely use the simpler left 
concatenation that adds a single assignment (x := v), noted x—iUW. 

Furthermore, application-specific mappings can be defined by inductive homomor- 
phisms. An inductive homomorphism O is defined by its evaluation on the 1 terminal 
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0(1) G ID, and its evaluation O' = 0(.r '' >d) for any x '' >d. O' is itself a (possibly 
inductive) homomorphism, that will be applied on the successor node d. The result of 
0((x,a)) is then defined as 'ZveDom(x) 0(x— T^a(v)). 



Inductive Homomorphism Examples: inc{x\ ) increments the value of the first occur- 
rence of the variable x\ . It returns T if xi is not part of the sequence. setCst{x\ , vi , V 2 ) 
assigns to each occurrence of xi the values in the range [vi , V 2 ] . The application of setCst 
to a simple DDD is shown below. 

inc(xi)(x, v) = 

f xTt)>M if X = xi 

\ X— ^Uinc(xi ) otherwise 
f«c(xi)(l) = 1 

setCst{a, l,2){a-^b-^a-^l) = 

a-^setCst{a,l,2){b-?i^a^-^l) + a^^setCst{a,l,2){b-^a^-^l) 

= a-^b-^setCst{a, l,2)(a^^.l) + a^^b~^setCst{a, l,2){a-^l) 

_ 1 ^ 2 /^ a— ^^efCs^(a, 1,2)(1) + \ ^ 2 ^ 2 ( a~^setCst{a, 1, 2){1) +\ 

y a^-^.^efCsf(a, 1,2)(1) J \^a^^setCst{a, 1, 2){l) j 

1/2 111 li2 2i| 2r2 111 2/2 2i 

— G >b ^ 1 ~h G ^G ^ 1 ~h G ^b ^G ^ 1 ~h G yb >G y 1 

Like in BDD packages, a hash table is used to ensure the unicity of DDD nodes. 
Moreover, a cache is maintained by the library to store the result of the application of 
a homomorphism to a DDD. Thus, although the expression setCst{a, 1 , 2) 1 ) 

needs to be evaluated twice, the second evaluation will constitute a constant time cache 
hit. 

2.2 Well-Formed Net and Symbolic Reachability Set (SRS) 

Symbolic markings (SM) are equivalence classes of states constructed using symme- 
tries that are computed before starting to explore the state space. The tokens which 
have structurally similar behaviour, i.e. that can be exchanged at any point in the evolu- 
tion of the system with no impact on the sequences of fireable transitions, are grouped 
into “static subclasses” (slow and fast processors for instance), which are not modified 
during the construction. In contrast “dynamic subclasses” are introduced to represent 
sets of tokens that have the same distribution throughout the places of the model. Al- 
though the number and cardinality of these dynamic subclasses evolve during the SRS 
construction, dynamic subclasses always constitute a partition of static subclasses (the 
slow processors that are waiting and those that are at rest for instance). Thus dynamic 
subclasses concisely represent the permutations that are permitted on an SM without 
modifying future sequences of fireable transitions. 



^efCs^(xl,Vl,V 2 )(x, v) = 

J 'Lv'e[vi,v 2 \^^setCst{xi,vi,V 2 ) ifx = xi 

1 x^^setCst{x \ , vi , V 2 ) otherwise 

^e^Csf(xl,Vl,V2)(l) = 1 
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Client 

<cl>i-<c2>i-<c3> 




Req 

<cli,serv> <cli,serv> 

<ser' 

l<cb> <cli,serv> I 

Wait Treat (T 



<serv> 



<cli> 



<cli> 



<cli,serv> ^ 



Resp 



<cli> 




clients = {cl,c2,c3};servers = {il,s2} 



Server 

<sl>+<s2> 



Fig. 1. Client Server Protocol 



We now informally explain the SRS construction through a simple example. A cod- 
ing of SM is also introduced, and will be reused in section 3 in our DDD representation. 
For a more formal description of SRS algorithms, please refer to [1]. 

Figure 1 represents a simple client server protocol. The system is composed of 
clients, initially positioned in place Client and of servers initially in place Server. At 
some point, a client can emit a request for treatment by firing transition ti , thus gen- 
erating a request in Req for an arbitrary server serv (the parameter serv is “free” and 
may be bound to any server). The client then waits for a response from the server in 
place Wait. When the chosen server is available, it will fire t 2 , consuming the request 
and placing the server in place Treat. When treatment is finished, the server generates a 
response in Resp for the client and returns to place Server by firing t^. Finally the client 
can acknowledge the reply by t 4 , and return to its initial state. 

It can be noticed that whatever their numbers, all clients and respectively servers, 
have a symmetric role. The structural symmetry analysis module therefore places all 
clients in a single static subclass C and all servers in a static subclass S (here, there 
is no need of further refinements into static subclasses). As they are equal, we will 
not distinguish C from clients and S from servers. The initial symbolic marking ,5b 
is expressed symbolically by the expression jb = Client {Zco) + Server{Zso), \Zco\ = 
3, jZ^ol = 2 ; this SM corresponds to the concrete initial marking: Client {c\ -I-C2-I-C3) -I- 
Server{s\ -I- 52)- Zco and Z50 are the dynamic subclasses which respectively represent 
the clients in place Client and the servers in place Server. As we can see, permuting 
elements within a Z, does not modify the marking, as all elements within a Z, have the 
same distribution over all places. 

From the concrete initial marking, 6 firings of t\ are possible, since cli may be 
bound to any ci , C2, C3 and independently serv can be bound to or S 2 - However, since 
all elements within a dynamic subclass Z,- are fully equivalent, there is only one way to 
bind a variable to any Z, , whatever it’s cardinality. Hence, a single symbolic binding is 
possible from the SM ,5b, cli is bound to (a value in) Zco and serv to (a value in) Zsq. 
To compute the firing, we first isolate Zci as the value bound to cli and Z51 as the value 
bound to serv. We can then modify the distribution of these new dynamic subclasses, 
by applying pre and post arc functions of t\. We obtain the SM 5i = Client{Zco) + 
Server{Zso + Zsi) + Wait{Zci) + Req{{Zci,Zsi)) , \Zco\ = 2, |Zci| = 1, IZ50I = \Zsi\ = 1. 
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This distribution of clients into Zq can be encoded by clients= (21) specifying the 
cardinalities of the Zq, and similarly servers = (l l). The place markings can be 
coded by: Client = ( 1 O) \ Server = ( 1 1 ) ;Wait = (O 1 ), indicating that place Client 
contains 1 * Zco + 0 * Zci , etc. . . The marking of place Req is defined over the colour 

domain clients x servers and can be represented by a matrix Req = f q ^ j > indicating 



it contains 0* (ZcOiZyo) + 0* (ZcOjZji) + 0* (Zci,Z5o) + 1 * (ZcijZ^i). 

We have shown how firing may split dynamic subclasses ; to exhibit the grouping of 
dynamic subclasses, let us fire t\ again, cli must be bound to a token present in Client, 
therefore must be bound to Zco, but serv may be bound either to Zsi or Z$ 2 - This yields 
two possible symbolic firings of ti, instead of the 24 concrete possible firings. 

Let us detail the firing cli G Zco, serv G Zsq: the second request is addressed to 
the same server as the first one. Again we split Zco to distinguish Zc 2 , the value cli 
is bound to. The marking obtained is Client{Zco) + Server(Z$o + -Zj! ) + Wait{Zci + 
Zci) + Req{{Zci,Zso) + {Zc 2 ,Zso)),\Zco\ = \Zc\\ = |Zc 2 | = 1 and \Zso\ = \Zsi\ = 1. 
This SM can be coded by the tensors: clients = ( 1 1 1 ) and servers = ( 1 1 ) giving 
the Z, and 



Server = ( 1 1 ) , Client = ( 1 0 0), Wait = ( 0 1 1 ) and Req = 




We can observe that Zci and Zc 2 have the same distribution in all places in this 
configuration. Indeed for any place P of domain clients, P[l] = P[2] and for place Req, 
the second and third lines are equal. We therefore group them in a single subclass of 
cardinality 2. The resulting SM 5s is: clients = (2 1 ) , servers = ( 1 1 ) giving the Z,- 

and Server = ( 1 1 ), Client = (O 1 ), Wait = ( 1 O) and Req = . It should be 

noted that the Zq dynamic subclasses have been reindexed, in order to have |Zco| > 
|Zci I ; this reordering is necessary to ensure the unicity of representation of the SM, 
and will be discussed in detail within Section 5.2. 



3 State Encoding 

3.1 Tensor Coding 

As our example in section 2.2 has shown, the data that need to be stored are expressed 
in terms of variable length vectors, matrices or more generally tensors. The mechanism 
used to store a vector of size n is simply to repeat a same variable V n times. More- 
over, a vector is always terminated by an End marker, represented by an occurrence of 
L— Although the number of repeats of V may vary along paths within our DDD, 
the variables always occur in the same order, thus the V always leads to the same 
variable. This ensures that our structures can be safely united, intersected, etc without 
risk of creating T terminals. 

As we have seen, the marking of a place P of arbitrary domain D = Cti 
can be stored as an n-tensor, n being the number of classes composing D. We therefore 
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need a representation of an «-tensor over what is basically a linear coding, as a DDD 
stores a sequence of variable/value pairs. Furthermore the operations we need to dehne 
manipulate (n — 1 ) -tensors extracted from an n-tensor, such as lines of a matrix, or faces 
of a cubic 3-tensor, so we need to easily determine where to find the elements of an 
(n — 1) -tensor. We have chosen a lexicographic coding, which meets our requirements, 
and is a generalization of the coding used for simple vectors. 

Let t be an n-tensor of dimensions cIqx ■■■ x d„-i. Let aio.i'i, - i„_i be an element of 
the tensor. The elements of the tensor t are encountered in lexicographic order: ao. 0,0~*’ 
ao,-o,i ^ > ao,-o,( 4 _i-i) ^ ao,-i,o ^ . .. ^ are try- 

ing to characterize the elements of a target (n — l)-tensor. For instance Vi G [0 • • • fifi — 
l],fl 3 , would give the elements of line 3 of a matrix. Let dk be the target dimension, 
and V the target index along this dimension. In our example. A: = 0 and v = 3. 

Property 1. Let n = JJ^-^/idj and p = 5 the indexes i of the elements of the 

(n-l)-tensor along dimension k satisfy: 

v-Jt < i < (v-f 1) • 71 mod{p). 

Where the whole inequation is evaluated modulus p. The proof of this property is 
straightforward and is omitted here. 

Let us apply this property to an example 2-tensor (a matrix) of dimension 3x4: 
The indexes i of the second line are given byA: = 0;v = l',K = d\ = 
4;/r = (io • = 12; thus 4 < i < 8 mod{l2). 

In the same way the third column is found at indexes i computed by: 
k= l;v = 2;jt = l;p = di =4; thus 2<i <3 mod{4). 

Generally the indexes of the elements of a (n-l)-tensor are not contiguous within 
the structure, however operations don’t need to read all the values to begin process- 
ing the operation. For instance, an operation comparing the second and third columns, 
needs only to store the value at index 2, to compare it to value at index 3 when it is 
reached, then if they are not equal the result can directly be given, else values 2 and 3 
are “dropped” and the process will be iterated for the next element of index i meeting 
the 2< i <3 mod{4) criterion. 

3.2 States and Motifs 

In this section, we present our coding of symbolic states (SM). This coding was devel- 
oped with two preoccupations: allow the definition of the symbolic firing relation and of 
the canonization operation with algorithms that only need to perform a unique traversal 
of the structure to determine their results. This means that the decision of what must be 
done on a node n only depends on the path traversed from the root to n and not on what 
may follow. In effect an algorithm that respects this constraint is at most of polynomial 
complexity over the size in number of nodes of the DDD. The second preoccupation is 
to obtain a high level of sharing within the representation. 

The data stored for each state is organized in motifs. Two primary motifs are dis- 
tinguished: the class motif corresponding to the definition of the partition of a static 
subclass C, into dynamic subclasses Z, (C motif) and the motif corresponding to the 
marking of a place (M motif). 



/O 1 2 3 
45 6 7 
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(a) A sample C motif: 

(b) A sample M motif: M— Uiff— UM— 

(c) A matrix M motif: 

(d) Place Treat is marked by: that is interpreted as a 2 x 1 matrix if coming 

from the top branch or as a 1 x 2 matrix if coming from the bottom branch. 

Fig. 2. Client Server Protocol, 2 clients, 2 servers: 12 symbolic states 



C motif, or class definition motif: The current distribution of each class or static 
subclass Ci into Zqj subclasses. As we have seen in section 2.2 this can be coded as 
a variable length vector of integers. As the marking evolves, the number, cardinality and 
order of these subclasses is modified, subclasses being split up whenever a particular 
token is extracted, and merged whenever they have the same distribution. 

M motif or marking motif: Given a partition into dynamic subclasses, a marking 
of a place is expressed as the number of times m each subclass or combination of sub- 
classes (i.e. m* < ZqiiZcjO >) is present in the place. We represent the marking of 
a place of domain Co x • • • C„_i by an «-tensor, of dimensions dc^ x • • • where dQ 
is the current number of dynamic subclasses in C, . 

Figure 2 depicts the state space for our client server protocol with 2 clients and 2 
servers. The figure reads from left to right, the root of our DDD being the colour domain 
definition of clients, and the last place described is Treat, which leads to the 1 terminal 
node not represented here. This diagram is an abstraction of the real DDD, as we have 
directly labeled arcs with tensors (vectors, matrices), instead of repeating the variable 
and representing the V End marker. Furthermore, we have named the variables to 
allow correspondence with the model, but all M motifs use the same variable M, and 
all C motifs use the same variable Z. Some sharing amongst paths of our representation 
is obvious here. As the size of the example increases, so does sharing, as we will discuss 
in section 7. 
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The state shown in bold corresponds to a state where clients are distributed into 
two dynamic subclasses Zco and Zci both of cardinality one, the place Client is empty, 
the place wait contains Zco + Zci , place Resp is empty, the servers are distributed into 
two dynamic subclasses Zso and Z$i both of cardinality one, place Server contains one 
server Zso, place Req contains one request {Zco,Zs\), and Treat contains {Zc\,Zs\). 
Thus in english, both clients are waiting for a reply and their requests target the same 
server Zs \ , one request is being treated and the other has not yet been received. The 
state that differs only by the marking of Req corresponds an analogous state except the 
client’s requests are not for the same server. 

3.3 Operation Framework 

Our prototype is developed in C++, and takes full advantage of both inheritance and 
template arguments to provide an open framework in which to code operations over 
these motifs. Thus an abstract operation class provides the functionality required to 
keep track of the current position within the motif and the concrete operations inherit 
this behaviour. 

When exploring the DDD seen as a tree, this generic operation stores the tensors 
encountered; upon reaching an ji End marker, the tensor that has been stored is passed 
to the concrete operation being run for evaluation. Thus our generic operation reads the 
tensor values represented on the arcs of Figure 2 into a DDD 9vi, evaluates a concrete 
operation on the extracted tensors M' = op{args){iM), and continues evaluation based 
on the value of iM'. 

This means that each place marking is isolated before running an operation on it, 
and since the number of possible place markings (actual different matrices on the arcs 
of figure 2) is low with respect to the combinations of place markings, sharing is high 
on the actual operations performed on tensors, although the storage phase has a higher 
complexity due to lower sharing. Furthermore, except for the transition bring operation, 
operations are evaluated independently of the actual place being considered, thus the 
concrete operation run on the extracted tensors have less arguments. In effect it means 
tensor operations are independent of the position of the tensor within the full state motif, 
thus operations on different place marking matrices can be shared, increasing the cache 
hit ratio. 

4 Symbolic Firing Operation 

As we have seen in section 2.2, there is only one way to bind a variable to any Z,-, what- 
ever it’s cardinality. However, if the dynamic subclass Z, a variable X is being bound to 
has a cardinality c > 1, a new dynamic subclass Zx of cardinality 1 must be created to 
isolate the value X is bound to. With Zx isolated, one can test if a place contains X by 
using the number of occurrences of Zx in P, or add Z in F by incrementing the num- 
ber of occurrences of Zx in P. An operation “add dim” is debned to create these new 
dynamic subclasses as needed. This operation simply copies the {n— 1) -tensor corre- 
sponding to Z, in position i-1- 1, prior to evaluating the inhibitor, pre, and post functions 
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for the considered place. On the other hand, if X is bound to a class Z, of cardinality 
one, no new subclass need be created, we can use Zx = Z, . 

The transition relation is defined as operating over a set of SM represented by 
a DDD. But since it is implemented by an inductive homomorphism, we describe the 
behaviour of the transition as a visit of the word constituting a single SM S- A transition 
thus has the following behaviour: 

1. When encountering a colour domain definition C, all the possible variable bindings 
are constructed. A variable binding {vars, adim) is composed of the correspondence 
variable to dynamic subclass index vars, and of the associated “add dim” operation 
adim that should be applied prior to evaluating the arc functions. Illegal variable 
bindings with respect to the guard of the transition are filtered out in this phase. 
Then a composite operation defined as a sum of all possible bindings is returned 
for evaluation on the rest of the SM. 

2. When encountering a place marking the adim operation corresponding to the 
current variable bindings is first applied. Then the colour functions associated to the 
current place are evaluated. If a pre or inhibitor function returns the 0 terminal, the 
transition stops evaluation and it’s homomorphism returns 0 thus pruning the par- 
tially constructed resulting marking from the DDD. Otherwise the newly obtained 
marking is inserted and the operation continues. 

3. If a transition reaches the 1 terminal the transition has been successfully fired with 
the current variable bindings. 

Colour functions are compositions of the three basic colour functions: diffusion 
noted S, identity represented by a formal parameter X, and only for ordered colour do- 
mains the successor operation A -f -f. These colour functions may have a multiplicative 
factor associated. For instance 2- < A > -f < T >, or < S,X > -f2- < A,T > are pos- 
sible colour functions labeling an arc to or from a place of domain respectively C and 
CxC. 

Given the definition of a place’s colour domain, the number of dynamic subclasses 
in each of the C, that form the domain, and the bindings of all variables or formal pa- 
rameters to their Z, , we compute the indexes in the M motif that are targeted by a colour 
function, and the multiplicative factor m associated to these indexes. This computa- 
tion is common to all types of arcs; given this list of target indexes and multiplicities, 
a homomorphism specific to the type of arc is applied for each target index i. These 
homomorphisms are defined by (inhibitor not represented) : 



W^{i,m){x,v) = 

if i^O x—^%'^(i— l,m) 

else if V > m x^^Id 

else =:> 0 
T1/-(1) = T 



%'^(i,m)(x,v) = 
f if i^O ^ x^f^W^(i—l,m) 
X else ^ xf±!^Id 
TV+(1) =T 



Where W , are respectively the pre and post arc operations. None of these 
operations should ever encounter the 1 terminal as the index i that is targeted will be 
reached before, and reaching i terminates the operation. 
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5 Canonization Algorithms 

This section presents the operations that we have defined to implement the canonization 
algorithms. The construction of the SRS is based on the notion of canonic representation 
for an equivalence class of states. From a symbolic state S, a transition is fired yielding 
a new symbolic state 5i ■ 5i is then minimized by groupings of dynamic Z, subclasses 
and canonized to ensure the unicity of its representation. 

As we have seen, the firing of a transition is liable to create new dynamic subclasses 
bound to the different formal parameters of the transition, and changes the distribution 
of dynamic subclasses within an SM. The goal of the minimization operation is to group 
dynamic subclasses that have the same distribution in all places, yielding a reduced ex- 
pression of place markings. This can be accomplished by testing for any two dynamic 
subclasses Z,- and Zj whether the (n — 1 ) -tensor corresponding to them are equal in all M 
motifs of the SM. Once all possible groupings have been accomplished, we must ensure 
that a state has a unique representation by finding an indexation of dynamic subclasses 
that yields a “minimal” or canonic representant for a state. To this end, we define a to- 
tal order on SMs that are equivalent up to a permutation of Z,, and use the smallest 
according to this order as canonic representative. This stage is called the canonization 
phase. 

5.1 Minimization 

The group operation consists in testing for all target colour classes C of index tC, 
whether any two dynamic subclasses Z, and Zj can be grouped into a single dynamic 
subclass such that \Zk \ = |Z,| + \Zj\. This is possible iff all places have the same marking 
with respect to Z, and Zj. 

The group operation follows the generic schema described in section 3. Its spe- 
cific operation arguments are i,j the indexes of the subclasses to be grouped if pos- 
sible within the target class tC. The operation is initially created with the values 
tC = i = 7 = — 1 meaning that none of these values are bound yet. A group operation 
group{tC,i,j){S) thus has the following behaviour: 

1. Upon encountering a new colour domain Q, if tC is yet unbound the oper- 
ation binds to Q and lets run the operation with tC unbound by returning 
group{—l, — l, — l) + group{k, — l, — l). If tC is already bound the operation fol- 
lows its course normally. 

2. When traversing its definition in terms of Z and their cardinality, all possible bind- 
ings of i and j are constructed and summed. 

3. Upon reaching the end of an M motif a first operation groupable is run on M 
to test whether the group operation is possible with the currently values of i and j. 
This operation tests the equality of lines i and j of iTf and breaks by returning the 0 
terminal at the first difference. If !M allows grouping, a second operation is run that 
deletes the values of line j from !M. If groupable returns 0, the global operation 
also returns 0, pruning the state being constructed from the full DDD. 

It should be noted that the group operation thus defined prunes any state that does 
not allow any grouping. Moreover, whenever two (or more) groupings are possible on 
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an SM, a single call of the group operation will create two partially grouped SMs. 
Given the DDD of the newly reached markings, the group operation is therefore called 
iteratively to stability as in: 
group -iter (5): 
while groupable (5) 7^ 0 do 

S ^ S- groupable ( 5 )+ group ( 5 ) 
end while 

5.2 Canonization 

In order to obtain a canonic representative of a state, we need to select one of the 
permutations of dynamic subclass indexes as the canonic one. This is done by sorting 
our DDD. Any ordering criterion is appropriate, as long as it defines a total order over 
permutations of the Z,s. But to keep the complexity of our operation reasonable, it is 
essential to define a criterion that can be evaluated as we travel from the root of our 
DDD to the terminals. 

Our sort is thus based on two levels of sort: 

- The first level of sort is cardinality based: we require that dynamic subclasses Z, be 
encountered in decreasing order of size. This can be evaluated as soon as a C motif 
definition is encountered. 

- Then for two Z, ,Zj of equal cardinality, we use a lexical sort that defines a total 
order over tensors of same size. 

We define a swap operation that swaps two adjacent Z, and Z,+i through a whole 
SM. The behaviour of our sort homomorphism is defined by: 

1 . Within a C motif, when comparing |Z,j to |Z,+i |, three cases are possible: 

(a) |Z,j > |Z,+i|: The order is already correct, iterate over the next Z,+i ,Z,+2 

(b) |Z, ,j < |Z,+i|: The order is wrong, the procedure swaps Z, andZ,+i over the rest 
of the state 

(c) |Z,j = |Z,+i|: Apply a lexical sort on lines i and /+ 1 then continue over the 
nextZ,+i,Z,+2 

2 . Upon reading a place marking tensor M for place P, which will only happen if 
the cardinality sort failed (|Z,j = |Z,+i |), we compute M' ^swap(i, i + \){M) and 
compare M to M' lexicographically. 

(a) If tTf = tTf', M is put back as marking of P and the lexical sort operation 
continues downwards, 

(b) if M < M' then M' replaces the previous M as marking of P and a swap 
operation is applied downwards, 

(c) if > ‘M' then the DDD is already sorted, tTf is put back and the identity 
homomorphism is returned. 

As a single application of the sort operation may not be enough to fully sort a set 
of states, a sort Jter procedure is defined, that simply iteratively calls the sort homo- 
morphism to stability. When stability is reached, we are ensured that all the SMs of the 
DDD are fully canonic. 
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6 Building the State Space 

We have defined the following operations in the previous sections, all applicable to a set 
of states S’- 

- fire{S,t)' fires the transition t for all possible variable bindings over a set of states 
^(section 4). The states returned are not canonical however. 

- group Jter{S)'- Groups the Z, that are groupable of a set of states ^(section 5.1). 

- sortJter{S)'- Sorts the states of a set S (section 5.2). 

The canonized successors of a set of states S by symbolic firing of a transition t, for all 
possible bindings of t’s variables, is obtained by: 
succ 

S ^fire{S,t) {Obtain successors (non-canonic)} 

S <— sortJter(S) {Apply a canonization (sort)} 

S <— group Jter{S) {Apply minimization (group)} 

S ^ sortJter(S) {Canonize the result (sort)} 

Let us note that sort is applied twice in the succ operation, which may seem counter- 
productive. Indeed, the group operation will operate correctly whether the Z,- are sorted 
or not. But in fact this accelerates the procedure because the first sort may reduce the 
number of states in S, as it only keeps one “version” of states identical up to a permuta- 
tion of Z, . Furthermore the cache for the group operation is used more efficiently as the 
input S for the group operation is always sorted, and the number of sorted SMs (canonic 
representatives) is very small w.r.t. the number of unsorted SMs. Finally the second sort 
comes at a very low cost, as the result of the first sort is still in cache. Thus the full sort 
operation is only fully evaluated on the newly grouped SMs (this last assertion is only 
mostly true, since it assumes that most of the nodes in groupJter(5) already existed 
in 5). 

Given this succ operation, the state space reached from a set of initial states S by 
firing a set of transitions T is computed by the following algorithm : 

srs (5,'T): 

5i ^5 

repeat 

for all t G T do 

5i ^ saturate{Si,t) 

do garbage collection 

end for 

until 5i = 5 

We initiate a construction of the full SRS by invoking srs{So,%ii) where 5b is the 
initial state and is the set of all transitions of the model. Thus the algorithm is based 
on two fixpoint computations: the first fires a transition until it is no longer fireable 
(saturate), the second saturates the firings of each transition successively until no new 
states are reached (our main srs). This double fixpoint method heuristically gives good 
results, because the cache doesn’t need to be cleared within saturate (though in truth, we 



With: 

saturate (S,t)'. 

Si^S 

Si^S 

repeat 

5i <— succ{Si,t) 
A <— A + 5i 

until Si = S 
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do garbage collection whenever memory consumption exceeds reasonable limits). The 
cache doesn’t overfill as the operations are exactly the same in each loop of saturate, 
whereas we cannot hope to store all the intermediate results constructed during a loop 
of srs. 

It also tends to saturate place markings, thus increasing sharing: when all the pos- 
sible markings of a place have been reached, sharing between states and operations 
increases. This can be understood by considering a system composed of two unre- 
lated places Pi and P 2 ; if Pi has n possible markings and P 2 has m possible markings; 
when adding newly reached states sharing in the structure will be poor at first, until 
enough states have been added to allow sharing, and ultimately we will only require 
two nodes Pi““ n^iues^_ favours cache hit, as a transition that only 

touches Pi will return Id upon reaching P 2 , thus all reached markings of P 2 will be 
concatenated to the new value of Pi . 

The evaluation order of transitions also plays an important role on the number of it- 
erations required to reach the fixpoint. The heuristic used to order transitions is to follow 
approximate flows: we start by evaluating transitions which have all their input places 
initially marked (whatever their marking thus the approximation); all output places of 
these transitions are then noted as marked, and the next transitions to be evaluated are 
again those that have all their input places marked, etc ... Although very simple, this 
heuristic has given good results over the models tested (2 or 3 iterations). 

7 Implementation and Results 

The table below gives an overview of the performances of our prototype over a few 
examples taken from literature. The models presented are: 

- Peterson’s mutual exclusion algorithm for n processes [5]. This protocol is not 
strongly symmetric: although the process identities {pid) can be abstracted away, 
one must keep track of the level of each process. 

- A critical section(CS) protocol with waves ensuring fairness [6]. Processes consti- 
tute a wave, then the wave is locked: idle processes can no longer enter the wave 
until the whole wave has passed into CS. Furthermore, processes within a wave are 
let through into CS in a static order specihed by their pid. Although this protocol 
may seem asymmetric, it functions by taking the process with highest pid from 
a set (the wave) and allowing it into CS. If no other transition of the model distin- 
guishes processes by their identities, we can consider all pids equivalent: indeed in 
any case one of the processes will be let through. The performances reported isolate 
the process of lowest pid 1 in a static subclass. Thus the SRS generated could allow 
verihcation of properties such as: the process of pid = 1 is always last of his wave 
to be let into CS. 

- A distributed database protocol [7]. This model exhibits considerable symmetry, 
and allows a high level of sharing within the DDD representation. 

- The client server protocol presented in section 1 . The performances over this model 
are parameterized by the number of clients (first column) and the number of servers 
(second column). 
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For each model, the number of concrete states is given (this in an over- 
approximation for the CS Wave protocol), the number of SMs, the number of nodes 
in the full SRS, the average share (80% share means the reduced DDD representation 
is 20% of the size of the decision tree with no sharing), the average length of the paths 
of the resulting DDD in number of nodes (DDDs of SMs have variable length path as 
we have seen), and the time to compute the SRS are given. 



Model 


N 


States 


SM 


final nodes 


Avg share 


Avg SM len 


SRS time 




(#) 


(#) 


(#) 


(#) 


(%) 


(# nodes) 


(sec) 




7 




692777 


320 


6159 


65.3 % 


55.5 


15.7 


peterson 


10 


3.46-10® 


3328 


42442 


85.1% 


85.9 


247.0 




11 


7.19- 10'° 


7168 


74039 


89.4 % 


97.3 


545.4 




12 


1.62- 10'2 


15360 


126807 


92.4% 


109.6 


1946.4 




40 


1.74- 10^® 


5620 


831 


99.3% 


23.8 


14.83 


CS Wave 


100 


1.76- 10^® 


35050 


1011 


99.8% 


24.0 


127.88 




200 


1.79- 10®^ 


140100 


1313 


99.9% 


24.07 


1041.75 




300 


1.02-10^^' 


315150 


1600 


99.98 % 


24.09 


3h20 




40 


1.77- 10®' 


20101 


725 


99.8% 


27.6 


56.95 


dist. DB 


300 


5.39-10^™ 


45151 


875 


99.93% 


27.6 


205.45 




500 


4.01 • 10“2 


125251 


1175 


99.96% 


27.6 


1841.68 




700 


4.89- 10®3 


245351 


1482 


99.97% 


27.6 


8 hours 




5 


2 


5484 


82 


884 


67.1 % 


32.7 


3 




10 


2 


1.35-10’ 


476 


2419 


86.3 % 


37.11 


28.56 




20 


2 


4.17- 10'3 


3201 


2914 


97.7 % 


40.4 


116.92 


Cli. Serv. 


6 


6 


2.44- 10' 


281 


4091 


72.5 % 


53.1 


21.2 




8 


8 


1.12- lO" 


964 


13123 


80.5 % 


69.8 


170.4 




9 


9 


1.05- 10'3 


1698 


22016 


83.5 % 


78.8 


450.5 



We can observe that the representation is extremely dense, with as many as 4.8 • 
10®^^ concrete states represented by only 1500 nodes. This is mainly due to the low 
number of SMs representing such a state space, only 245,000 in this instance. The 
average length of an SM, which corresponds to the average number of dynamic sub- 
classes in a static subclass, asymptotically tends toward a structural limit imposed by 
the P-invariants of the models studied, thus does not follow the evolution of N. For the 
client/server however, we have worst case SMs with M tensors of size N^. 

Unfortunately computation time does not directly follow the number of nodes. In- 
deed, the number of SMs is a clear component of the time complexity. This is partly due 
to the fact that the complexity of evaluating an operation on a node is necessarily linear 
to the number of sons, as the inductive homomorphism is applied to each son. Our com- 
pact encoding generates nodes with a very high number of sons, particularly when the 
P-invariant bounds have been reached, and only the cardinalities of the Z, change from 
one SM to another. We also attribute this in part to the fact that the DDD library is still at 
a prototype stage, and that caching policies in particular are inefficient. This could cer- 
tainly be improved by integrating into the DDD library caching and accelerated access 
algorithms developed for other variants of BDDs [11]. 
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8 Conclusion 

We have shown in this paper how the algorithms for SRG construction [ ] can be im- 
plemented over a DDD [4] representation. The key idea is to exploit both explicitly 
expressed symmetries by building equivalence classes of states (SMs), and implicit 
symmetry through the similarities in the representation of these SM. The flexibility of- 
fered by DDDs and inductive homomorphisms allows to both represent and operate 
over complex and dynamic structures, such as the tensors representing place markings 
in an SM. The prototype developed shows that extremely compact encodings of a state 
space can be obtained, allowing storage of 4.8 • 10®^^ states on 1,500 nodes. Memory 
consumption is thus very low, however time complexity remains high. 

Further directions include improving the DDD library core, with respect to our spe- 
cific needs, and developing a full LTL model checker using the symbolic observation 
graph method [9]. We are also interested in developing extensions of the SRG con- 
struction, such as the ESRG construction [6] that captures partial symmetries, using our 
symbolic symbolic framework. 
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Abstract. The main goal of this paper is to extend sPBC with the iter- 
ation operator, providing an operational semantics for the language, as 
well as a denotational semantics, which is based on stochastic Petri nets. 
With this new operator we can model some repetitive behaviours, and 
then we obtain a formal method that can be easily used for the design 
of communication protocols and distributed systems. 

Keywords: Stochastic Petri Nets, Stochastic Process Algebra, Perfor- 
mance Evaluation, Petri Box Calculus 



1 Introduction 

Petri Box Calculus (PBC) [4, 3, 5, 6, 7] is an algebraic model for the specification 
of concurrent systems which has a natural and compositional translation into 
a special kind of labelled Petri nets, called boxes. The description of a wider 
class of systems, such as real-time systems and fault-tolerance systems, is the 
goal of two timed extensions of PBC that we may find in the literature, namely 
tPBC [11] and TPBC [15], both of them considering a deterministic model of 
time. In the same line we presented sPBC in [14, 13], which is a Markovian 
extension of PBC. 

In sPBC we consider that each multiaction has associated a delay which 
follows a Markovian distribution, as the transition delays of stochastic Petri 
Nets (SPNs) [1]. Thus, a stochastic multiaction of sPBC is represented by a pair 
< a,r >, where a represents a (classical) multiaction of PBC, and r G K’*' is the 
parameter of the associated exponential distribution. Moreover, as in SPNs, the 
race policy governs the dynamic behaviour. 

In the literature we may find some different approaches that deal with 
stochastic extensions of process algebras such as PEPA [10], TIPP [8] and 
EMPA [2]. There are some important differences with respect to them. In sPBC 
we allow multiactions (multisets of actions), we consider a synchronization op- 
erator totally independent from the parallel operator (as in PBC) and, finally, 

* This work has been supported by the MCyT project “Description and Performance of 
Distributed Systems and Application to Multimedia Systems, Ref. TIC2003-07848- 
c02-02” . 



D. de Frutos-Escrig and M. Nunez (Eds.): FORTE 2004, LNCS 3235, pp. 292—309, 2004. 
(c) IFIP International Federation for Information Processing 2004 
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we obtain the parameter of the new multiaction generated after synchronization 
following a different technique (see [9] for a complete discussion about all the 
different alternatives for that). 

The technique that we use is based on conflict rates, which are inspired in 
the apparent rates of PEPA [10]. Nevertheless, in our approach we can find 
an important advantage: we have been able to obtain a static translation into 
stochastic Petri nets, while in PEPA rates of transitions are in some cases mark- 
ing dependent [17]. 

In our two previous works we only considered finite sPBC [14, 13]. Then the 
aim of this paper is twofold: including in the syntax the iteration operator and 
proving that the operational and the denotational semantics (the latter based on 
a special kind of labelled SPNs, called s-boxes) are fully abstract. The iteration 
operator allows us to describe infinite behaviours and, therefore, it is a powerful 
tool to describe the behaviour of concurrent systems. Then, with this formalism 
we can deal with the design of communication protocols and distributed systems 
with a Markov time, but joining in a single model both the advantages of process 
algebras and Petri nets. 

This paper tries to be, as far as possible, self-contained, so we will first review 
the syntax, the operational semantics and the denotational semantics of the finite 
operators. For further details the reader is referred to the previous works of the 
authors [14, 13]. The paper is structured as follows: in Section 2 we present 
an overview of the syntax. The operational and the denotational semantics can 
be found in Sections 3 and 4, respectively. Section 5 contains an example, and 
finally. Section 6 contains some conclusions and our plans for future work. 



2 Syntax of Stochastic Petri Box Calculus 

In this section we present some notations and the syntax of sPBC, with an 
informal interpretation of the operators. In this paper we do not consider the re- 
cursion operator because it requires a more sophisticated treatment, as it occurs 
in plain PBC. Nevertheless, with the iteration operator we are expanding the 
power of description of sPBC significantly, and in fact some potentially infinite 
behaviours can be described with it. 



2.1 Notation 

From now onwards we will use the following notation: A will be a countable 
set of action names, V a G A, 3 a G A, such that a ^ a and a = a, as in 
CCS [16]. Letters a, b,a, ... will be used to denote the elements of A; £ = B{A), 
will represent the set of finite multisets of elements in A {multiactions) . We will 
consider relabelling functions f : A A, which are functions that preserve 
conjugates, i.e.: Va G A, /(a) = /(a). We will only consider bijective relabelling 
functions. We define the alphabet of a G £ by: A(a) = {a G A ] a(a) > 0}, 
and the set of stochastic multiactions by SC = {<a,r > |aG£,rG K+}. We 
allow the same multiaction a G £ to have different stochastic rates in the same 
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specification. Finally, we define the synchronization of multiactions: a0o/3 =def 
7 , where: 

(h\ — f if6 = aV6 = a 

' [ a(b) + ( 3 {b) otherwise 

which is only applicable when either a G A{a) and a G A{P), or a G A{a) and 
a G A{P). 

2.2 Syntax 

As in plain PBC, static s-expressions are used to describe the structure of a con- 
current system, while dynamic s-expressions describe the current state of a sys- 
tem (they correspond to unmarked and marked Petri nets, respectively). As 
a system evolves by executing multiactions, the dynamic s-expression describing 
its current state changes; this is captured by means of both overbars and un- 
derbars that decorate the static s-expression. Static s-expressions of sPBC are 
those defined by the following BNF expression: 

E ::= <a,r> \ E; E \ E a E \ E \\ E \ E[f] \ E sy a \ E rs a \ [a : E]\[E * E * E] 

where < a, r > G SC stands for the basic multiaction, which corresponds to 
the simultaneous execution of all the actions in a, after a delay that follows 
a negative exponential distribution with parameter r. E\ ; E2 stands for the 
sequential execution of E\ and E2 , while E\ □ E2 is the choice between its ar- 
guments, E[f] is the relabelling operator, and Ersa denotes the restriction 
over the single action a (this process cannot execute any stochastic multiactions 
<a,r > with either a G A(a) or a G A{a)). The parallel operator, ||, represents 
the (independent) parallel execution of both components, where there is no any 
synchronization embedded in the operator (as in PBC). Synchronization is in- 
troduced by the operator sy, thus the process E sy a behaves in the same way 
as E, but it can also execute those new multiactions generated by the synchro- 
nization of a pair of actions (a, a), [a : E] is the derived operator scoping defined 
by [a : E] = {E sy a) rs a. Finally, the iteration operator [Ei * E2 * A3] repre- 
sents the process that performs Ei, then executes several (possibly 0) times E2, 
and finishes after performing A3. We can obtain infinite behaviours by ade- 
quately combining both the iteration and the restriction operators; for instance, 
[< {a},ri > * < {b},r2 > * < {c},r3 >] rsc, represents the process that per- 
forms < {a},ri > once, and then it executes < {b},r2 > infinitely many times. 

However, we need to restrict the syntax of sPBC to those terms for which 
no parallel behaviour appears at the highest level in a choice or in the two last 
arguments of an iteration. In principle, with this restriction we slightly reduce 
the expressiveness of the language, although we could prefix parallel operators 
appearing at the highest level of a choice or in one argument of an iteration 
by an empty multiaction, whose rate could be adequately selected in order to 
preserve the probability of execution of the multiactions involved in the choice 
or in the iteration. Terms fulfilling this restriction will be called regular terms, 
and the operational semantics will be only defined for them. This restriction 
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is introduced in order to guarantee that the moment in which the rule for the 
synchronization is applied does not affect the value that we obtain for the rate 
of the stochastic multiaction obtained as result of a synchronization (this will 
be illustrated in Example 1). 

More exactly, regular static s-expressions E are those static s-expressions of 
sPBC fulfilling: 

D ::= <a,r > \ D', E \ D sy a \ D rs a \ D[f] \ [a : D] \ Dd D\[D * D * D] 

E ■.-.= <a,r>\E-E\Esya\Ersa \E[f] \[a:E]\E\\E\DOD\[E*D*D] 

The operational semantics of sPBC is defined on dynamic s-expressions G, 
which derive from the static s-expressions, annotating them with either upper or 
lower bars, which indicate the active components at the current instant of time. 
Thus, we have: 

G ■.■.= E\E\G] E\E]G\GUE\EUG\G\\G\ G[f] | G s?/ a | G rs a | 

[a : G]\[G * E * E]\[E * G * E]\[E * E * G] 

where E denotes the initial state of E, and E its final state. We will say that 
a dynamic s-expression is regular if the underlying static s-expression is regular. 
The set of regular dynamic s-expressions will be denoted by ReDynExpr. 



3 Operational Semantics 

We have two kind of transitions: inaction transitions, annotated with 0, which 
just denote a rewriting of a term by redistributing its bars, in order to prepare 
the term to apply new transitions; and stochastic transitions, which correspond 
to the execution of a stochastic multiaction. Therefore, inaction rules define in 
fact an equivalence between regular dynamic s-expressions as defined in Def. 2. 
Inaction rules for sPBC are those presented in Tables 1 and 2. 



Definition 1. We say that a regular dynamic s-expression G is operative if it 
is not possible to apply any inaction rule from it. We will denote the set of all 
the operative regular dynamic s-expressions by OpReDynExpr . □ 

Definition 2. We define the structural equivalence relation for regular dynamic 
s-expressions by: 



- (JL. I I JL'i* 

= =def ( > U < ) 

As usual, we denote the class of G with respect to = by [G]= . 



□ 



Rules defining the stochastic transitions are those presented in Table 3, to- 
gether with those corresponding to the synchronization operator, which will be 
described in detail later. We assume that all dynamic s-expressions that appear 
on the left-hand sides of each transition in the rules are regular and operative. 
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Table 1. Inaction rules (I) 



E-,F ^ E-,F 


E:,F BL, E- p 


E-,F^E-,F 


EOF EOF 


EOF EOF 


EOF EOF 


EOF EOF 


E\\F ^ £;||T 


E\\F-^ E\\F 


E[f] ^ Elf] 


E[f] ^ E[f] 


E sy a — E sy a 


^sy a — ^ E sy a 


h rs a — E rs a 


TP 0 T71 

E rs a — E rs a 


VopGi; , □}, G^G' 


VopGl; , □}, G^G' 


G^G' 


GopE -^G' opE 


E op G E op G’ 


G[f] ^ G’lf] 


Gi ^ G\ 


G2^G', 


Mop G {sy , rsj, G — ^ G' 


G 1 II G2 G'l IIG2 


GIIIG2 -^Gi II G2 


G op a G' op a 



Table 2. Inaction rnles (II) 



[E*F*E'] [E*F*E'] 


[E*F*E'] 


-^[E* F*E'] 


[E * F* E' ] ^ [E *F * E' ] 


[E*F*E'] 


-^[E*F*r'] 


[E*F*Ef] -^[E*F*E'] 


G 


^G' 


[G*E*F] 


[G' * E * F] 


G^G' 


G 


^G' 


[E*G*F] [E*G' *F] 


[E*F*G] 


-^[E*F*G'\ 



Rules in Table 3 define a total order semantics, in the sense that it is not 
contemplated the possibility of executing two multiactions at the same time. 
Then, in order to define the semantics of the synchronization operator, we need 
to calculate all the possible sets of bags of stochastic multiactions that could 
be executed concurrently as result of one or several synchronizations over each 
operative regular dynamic s-expression. 

Definition 3. We define BC : OpReDynExpr — s- V{B{SL)), as follows: 

— If G G OpReDynExpr is final, i.e. G=E, we take BC{G) = 0. 

— If G G OpReDynExpr is not final, we distinguish the following cases: 

• BC{< a,r>) = {{<a,r >}} 

• If-f G BC{G), then: 7 e BC{G; E), 7 e BC{E; G), 76 BC{E □ G), 7 S 
BC{GO E), 7 G BC{G rs a) (when a, a ^ ^(7)), 7 G BC(Gsya), 
fil) G RG(G[/]),7 e BC{[G * if * T]) , 7 G BC{[E * G * T]) , 7 G 
BC{[E * T * G]) . 

• //71 e BC{G), 72 G BC{H), then 71 G BC{G\\H), 72 G BC{G\\H), 
and 7i + 72 € BC{G\\H). 
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Table 3. Rules defining the stochastic transitions (I) 




• 7 GBC{G sy a), and < a,ri > , < P,r2 > € 7, (with either < a, ri >7^ 
< P,T2 > or they are two different instances of the same stochastic 
multiaction in j), with a G A{a), and a G A{I 3 ), then: 7' G BC{G sy a), 
w/iere; 7' = (7 + {< a ©a /3, i? >}) \ {< a, ri >, < /3, 7-2 >} and R is 
the rate of the new stochastic multiaction, to be later defined (see rule 
Sy 2 in Table 4 )- 



□ 

In order to define the rates for the stochastic multiactions generated by 
a synchronization we need to identify the situations of conflict. Concretely, for 
each operative regular dynamic s-expression G we define the multiset of associ- 
ated conflicts for every instance of a stochastic multiaction <a,r>i executable 
from G, which we will denote by ConfiictiG, < a,r >i), but we will only take 
those stochastic multiactions with exactly the same multiaction a. We will de- 
note this multiset of conflicts by Conflict{G, < a,r >i), although we will omit 
the subindex i if it is clear which instance of < a, r > we are considering 

Definition 4. We define the following partial function: 

Conflict : OpReDynExpr x S£ — > B{SC) 

which for each instance i of the stochastic multiaction < a,r > executable from G 
gives us the multiset of stochastic multiactions < a,r' > in conflict with it. We 
define the function in a structural way: 

^ To avoid a more sophisticated formal definition, we have preferred to omit the indices 
in the definition. 
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1. Conflict {< a,r >, < a,r >) = {< a,r >} 

2. If < a, r > is executable from G, and C = Conflict (G, < a,r >), then: 

(a) Conflict {G; E, < a,r >) = Conflict {E;G, < a,r >) = C , 

(b) Conflict (G||i^, <a,r >) = Conflict (i^ ||G, < a, r >) = G, 

(c) Ifa,d^A(a), then Conflict {G rs a, < a, r >) = C , 

(d) For any bijective function f, Conflict (G[/], < /(a),r >) = f{C), 

(e) For the choice operator we need to distinguish the following two cases: 

- If G ^ E : Conflict {GO F, < a,r >) = Conflict {F O G, < a,r >) = C 

- If G = E : Conflict {GO F, < a,r >) = Conflict {F O G, < a,r >) = 

G + ^ < a,Xj > \ 3Hi € OpReDynExpr , Hi = F and Hi H{ |} 

(f) For the iteration operator we have: 

— Conflict{ [G * E * F], < a^r >) = G 
— For the two last arguments of an iteration we have: 

- If G ^ E' : Conflict {[E * G * F],<a,r>) = 

Conflict {[E * F * G],<a,r>) = G 

- If G = E’ : Conflict {[E * G * F], < a,r >) = 

Conflict {[E * F * G], < a,r >) = G + 

H < a, Tj > \3Hi £ OpReDynExpr , Hi = E and Hi || 

(g) Conflict {G sy a, < a, r >) = C , 

3. Let {< ai,ri >,< a 2 ,V 2 >}€ BC {G sy a), a G A(o;i), d G A{a 2 ) and 

G sy a Qi ^ obtained by applying rule Sy2 . Then: 

Conflict (G sy a, < a\ ©o ct 2 , R 12 >) = 

H < ai ©a «2 , Rij > I <ai,ri >€ C'l: < «2, Tj >€ C2, where 



taking: Ci = Conflict{G sy a, < ai,Vi >), i = 1,2, and cr{G,< a,r >i) is 
the so called conflict rate for G and <a,r >i , defined by: 



where Uj is the number of instances of < a, Vj > in Conflict{G , <a,r >i). 



Rules for the synchronization operator are shown in Table 4. Observe that 
we take as rate of the generated stochastic multiaction the minimum of the 
conflict rates of <ai,ri>, <a 2 ,V 2 >, weighted by a factor, which is introduced 
in order to guarantee that an equivalence relation defined in [12] is in fact a 
congruence. For short, we will denote the stochastic multiaction obtained by 
synchronization of the stochastic multiactions < a\,ri > and < 02 ,r 2 > by 

< ai,ri > ©a < Q!2, C2 > . 




• min {cr{G sy a, < ai,ri >)} 

i—1,2 



cr{ G,<a,r >i) 



E 




□ 



Definition 5. For each G G ReDynExpr we define the set of the dynamic 
s-expressions that can be derived from [G]= by: 
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Table 4. Rules for the synchronization operator 




[G) = {G' I G' € [G]=} U {H' G ReDynExpr | 3 < «i, ri . 



with G = G' 



Gi = G'l 



<a2,r-2> 



. . . G„_i = G' 



. ,<a. 

<a 



n 5 

''n> 



>gsc 

H = H'} 

□ 



In [13] we proved for finite sPBC (without iteration) that for any bag 7 of 
stochastic multiactions executable from a regular dynamic s-expression G, any 
serialization of 7 can be executed from G, and the multiset of conflicts for any 
stochastic multiaction in 7 is preserved along the serialized execution of 7. This 
result can be easily extended to sPBC with iteration, and we can use it in order 
to compute the rate of the stochastic multiactions obtained after a number of 
synchronizations . 

Proposition 1. Let G he a regular operative dynamic s-expression, 7 = 
{< ai,ri >,< a 2 ,r 2 an,rn >} € BC{G), and a serialization of ■j, 

for which we may apply n — 1 times rule Sy2 : 

„ <ai,ri> , 0 <0:2, T2> <a„,r„> 

Lr > Czlt >) Lri > ... > Lr„ 

to obtain a single transition G ^ 

Then we have: 

n 

R = (^^ cr(G.<a„r,» ) ' >)} 

cr{G,<P,R>)= min {cr{G, < ak,Vk >)} 

k=l,...,n 

Proof. It can be found in [12]. □ 

Consequently, for all the possible transition sequences obtained by a serializa- 
tion of 7, if we can apply rule Sy2 a number of times to reach a single stochastic 
multiaction, then we have that it does not matter the order in which rule Sy2 
has been applied, neither the transition sequence used, i.e., we will always obtain 
the same stochastic multiaction. 
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Corollary 1. Let G be a regular operative dynamie s- expression, 7 = 

{< ai,ri >,< a2,r2 a„,rn >} G BC{G), and two permutations of 

the set {1, • • • ,n} : {i\, ■ ■ ■ , i„} and {j\, ■ ■ ■ ,jn}- Assuming that there are two 
serializations: 



G 

G 



«^3lXji> 



Gi{^)*Gl 



<ai^2> 

<aj2 > 



<Otir 

<Ctj. 



G„ 



G' 



from which we may apply n —1 times rule Sy 2 (for the same actions ai, . . . , a„_i, 
possibly repeated, but the same number of times in both cases), to obtain a single 



transition G q respectively, then we have: Gn 

G'„ and < Pi, Ri> = < Pj,Rj > ■ 



□ 



Now we show an example that motivates the need for the syntactical restric- 
tion introduced, specifically in the case of iteration. With this example we will 
raise the problem that appears when we consider a parallel behaviour in the 
highest level in the body of an iteration. 



Example 1 . Let G be the following non-regular operative dynamic s-expression: 



G= {[< {a}, ri > *{< {6}, r2 > || < {&}, rs > || < {b, b}, n >)* < {b}, rs > ] ) sy a 

It follows that 7 = {< {b},r2 >,< > < {b,b},r4 >} G BC{G). Then, 

according to the definition of BC, we also have 71 = {< {6}, r2 >, < {6}, R34 >} 
G BG (G), with 



R34 = ; min{v3 + rs, r4} 

r^ + r^ 

However, not every serialization of 71 is possible from G, because < {6},i?34 > 
cannot be executed from Gi, where G and 

Gi = ([< {a}, ri > *( < {h},V2 > || < {&}, rg > || < {6, 6}, r4 >)* < {b}, rs >]) sy a 

Actually, we can execute < {b},R'^4 > from Gi, with A34 = min{r3,r4}, and in 
general we have R34 yf R'^4. □ 

Definition 6. We define the labelled (multi)transition system of any regular 
dynamic s-expression G, ts{G) = {V,A,vq), where: 

— V = {[H]= \ H € [G)} is the set of states. 

— Vo = [G]= is the initial state. 

— A is the multiset of transitions, given by: 

A {[Hy,<Wr>, [JU)\H€[G) a H J ^ 
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In order to compute the number of different instances of each transition 
= , <a,r >, [J]=) in A, we consider equivalent all the different ways to derive 
the same stochastic transition by considering the different serializations of the 
same 7 ( Corollary 1 ). Therefore, for each equivalence class, we will only consider 
one of its representatives, which can be chosen imposing that the stochastic mul- 
tiactions in each 7 G BC{G) will be executed in the same order as they appear in 
the syntax of the s-expression G, i.e., we enumerate the stochastic multiactions 
from left to right in the syntax of the s-expression, and then, when we apply rule 
Sy2, the generated stochastic multiaction can be annotated with the concatena- 
tion of the numbering of the corresponding stochastic multiactions involved in 
the synchronization, so that when we detect that a permutation of the numbering 
has been already obtained, by a previous application of the rule, then that new 
stochastic transition will not be considered (see [I 4 ] for more details). □ 

The race policy will govern the dynamic behaviour of the system when two 
or more stochastic multiactions are simultaneously enabled (i.e., when several 
stochastic multiactions are possible, the fastest one will win the race). Then, as 
we are using exponential distributions, the stochastic process associated with the 
evolution of every regular dynamic s-expression if is a Continuous Time Markov 
Chain (CTMC), which can be easily obtained from ts{E) in the same way as 
we showed in [14]: we modify the multigraph ts{E) by combining into a single 
edge all the edges connecting the same pair of nodes. These new edges will be 
labelled by the sum of the rates of the combined edges. 

4 Denotational Semantics 

We now present a denotational semantics for s-expressions, which is obtained 
taking stochastic Petri nets as plain boxes. Therefore, the semantic objects that 
we use will be called stochastic Petri boxes or just s-boxes. Thus, these s-boxes are 
essentially SPNs, but they have the same structure as Petri boxes of PBC. These 
boxes of PBC are labelled Petri nets fulfilling some restrictions. Concretely, they 
are labelled Petri nets E = {S,T,W, X), where (S,T,W) is a Petri net, and A is 
a labelling function, which labels places with values from {e,i,x}, representing 
entry places, internal places, and exit places respectively; and transitions with 
elements in B{C) x C ; i.e., \{t) is a relation which associates elements of £ to bags 
of multiactions. By convention, °S and E° will denote the set of e-labelled places 
and the set of x-labelled places, respectively. Given a place s € S', we will denote 
by *s (s*) the set of input (output) transitions of s (called preconditions and 
postconditions of s, respectively). A similar notation is used for preconditions 
and postconditions of transitions. Both can be easily extended to sets of places 
and sets of transitions. Then, our boxes are defined to be labelled simple nets 
such that the following conditions hold: ° E S° , *(°A7) = 0 = (if°)* 

and yt G T : *t fft* . A box is said to be plain when for every t G T, X{t) 
is a constant relation, i.e., an element of £. 
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Definition 7. A plain stochastic Petri box (or just plain s-box^ is a tuple S = 
{S, T, W, A, p,), where (S', T, W, A) is a plain box, and p : T — > M+ is a stoehastic 
function, which associates a rate to every transition. □ 

A plain s-box can be either marked or not We will denote by Mg the 
marking in which only entry places are marked (each one with a single token); 
on the other hand, will denote the marking in which only exit places are 
marked, each one with a single token. We say that a marking M is fc-safe if for 
all s G S, M{s) < k, and we say that M is clean if it is not a proper super- 
multiset of “A nor E° . Then, a marked plain s-box is k-safe if all its reachable 
markings are k-safe, safe if all its its reachable markings are 1-safe, and clean if 
all its reachable markings are clean. 

4.1 Algebra of S-Boxes 

For each transition that we can obtain compositionally we need to know which 
transitions are in conflict with it, in order to compute its eonflict rates. Thus, 
we enumerate stochastic multiactions appearing from left to right in the syntax 
of regular static s-expressions, and we preserve this enumeration in the corre- 
sponding transitions of the stochastic Petri net. Only with the synchronization 
operator we can obtain some new transitions, which will be annotated with the 
concatenation of the numeration of the transitions involved. 

Another decision that we must take is the selection of the operator box 
that we will use for the iteration, since we have two proposals in plain PBC 
for that [5]; one of them provides us with a 1-safe version (with six transitions 
in the operator box), but there is also a simpler version, which has only three 
transitions in the operator box. In general, in PBC, with the latter version we 
may generate 2-safe nets, which only occurs when a parallel behaviour appears 
at the highest level of the body of the iteration. Nevertheless, in our case, and 
due to the syntactical restriction introduced, this particular case cannot occur, 
so that the net obtained will be always 1-safe. 

In order to define the semantic function that associates a plain s-box with 
every regular term of sPBC, we need to consider the following functions: 

rj :T — ^ N* and«: : T — > V{N*) 

where r](t) stands for the numeration of t according to our criterion (enumera- 
tion from left to right, and concatenation in case of synchronization), and n(t) 
identifies the set of transitions in conflict with t. These functions will be defined 
in a structural way, as we construct the corresponding plain s-box. 

For each transition t G T, we also define its corresponding confliet rate, and 
we will denote it by cr(t): 



cr{t) = 

v{tj)eK{t) 

^ A marked plain s-box is essentially a kind of marked labelled stochastic Petri net, 
whose behaviour follows the classical firing rule of SPNs. 
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Then, the structure of the net is obtained as in PBC, combining both refine- 
ment and relabelling. Consequently, the s-boxes thus obtained will be safe and 
clean. Therefore, the denotational semantics for regular static s-expressions can 
be formally defined by the following homomorphism: 



As previously mentioned, we have to define 77 , k for every operator of sPBC. 
- Boxs (< a, r >i) = N^a,r>i = 



taking r]{ti) = i and K{ti) = {*}. 

For the remaining operators of sPBC the corresponding operator s-boxes are 
shown in Fig. 1, where the relabelling functions pop C B{SC) x SC that appear 
in that Figure are defined as follows:^ 

■ Pid = {{{<a,r>},<a,r>)\ <a,r>^SC} 

■ P[/] = {({<«: '^ >}:</(«):»’>) I <a,r>€5£} 

■ Prsa = {{{< ct,r >}, <a,r >) \ <a,r>£SC A a,a ^ A{a)} 

Thus, the corresponding semantic functions are defined as follows, where 
BoXs{Ei) = (5'i, Ti, Wi, Xi, Pi) is the plain s-box corresponding to Ei, and iji , Ki 
are the enumeration and conflict functions for Ti, i = 1,2,3. 

— BoXs{Ei ; E 2 ) = f^-XBoXs(Ei) , BoXs{E 2 )) ■ Then, we take: 



— BoXs{Ei WE2) = fi\\{BoXs{Ei), BoXs{E2))- rj and k are defined in exactly 
the same way as in the previous case. 



B0Xs{< a, r >i) = N^a,r>i 

BoXs{op{Ei,...,En)) = nop{B0Xs{Ei),...,B0Xs{En)) 



ti 






BoXs{Ei[f\) = {BoXs (El)). 



v{t) = ? 7 i(t) , f € Ti and K{t) = Ki{t) , t € Ti 





^ We separate the definition of Psya, which will be presented later, when we formally 
define BoXs{Ei sya). 
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Fig. 1. The operator s-boxes for sPBC 



- BoXs{[Ei * E2 * Ez]) = Q[^^.}^{BoXs{Ei),BoXs{E2)tBoXs{Ez)). No new 
transitions are introduced with this operator, so the numeration of transi- 
tions is preserved. However, it is clear that this operator will introduce some 
new conflicts. Specifically, those transitions in T2 having their preconditions 
in ° BoXs{E2) are in conflict with those transitions in T3 with preconditions 
in ° BoXs{E^), if they have the same associated multiaction (the same la- 
bel). Notice that since we are working with regular terms, BoXs{E2) and 
BoXs{E^) will have a single entry place. Formally: 

f ^l(t) if t e Ti 
n(t) = { V2(*) if f e T 2 
[ ^s(*) if t e T 3 



K(t) 



(t) if t € 

«2(t) U «3(t^) if t € T2 , * t € ° Boxg {E2 ) , 3 € T’3 , * t' Boxs{E 2 ), A(t) = X{t' ) 

«2(t) ift€ T2 , * t € ° Boxs {E2 ) , /St' € T3 , * t' € ° Boxs (E3 ), A(t) = ^{t' ) 

«2(t) ift€ 2^2 , * t ^ ° Boxg {E2 ) 

K3(t) U 1^2 ) if * € T3 , * t € ° Boxs {S3 ) , 3 t' € T2 , * t' Box s{E2) , A(t) = A(t^) 

«3(t) ift€ T’3 , * t € ° Box 3 (S3 ) , ^ t' € T2 , * t' € ° Box 3 (S2 ), ■^(t) = ^{t' ) 

«,3(t) if t € T3, *f ^ °Boa:s{S3) 



Notice that n{t) is well deflned for the second and fifth cases, because 
coincides for every t' G T3, *t' G ° BoXsiE^), \{t) = X{t'), and respectively 
for the other case. 

- BoXs{Ei rs a) = {BoXg (Si) ). 



77(f) = rji{t) , f G Ti , a,a ^ \{t) and K{t) = Ki{t) , t G Ti , a, a ^ \{t) 
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— BoXs{Ei sya) = (2sya {BoXg (Ei) ). We take the following relation for the 
synchronization: p^ya C B{SC) x SC, as the least relabelling relation con- 
taining pid, and fulfilling: 



{r,a + {a}) & Psya A {A,(}+{a})&psya then {E + A,a + (}) & psya 



Thus, Psya allows us to obtain the net structure, as well as the multiactions 
labelling the transitions. Now, for every t\,t2 G Ti, A(ti) = ad- {a}, \{t2) = 
f3 + {a}, a new transition t is generated by the synchronization, whose label 
is a -I- / 3 , and its rate is computed as follows: 



Moreover, 



Mi(fi) 

cr{ti) 



Cih) 

cr{t2) 



min{cr{ti) , cr{t2)) 



p{t) = miti) ■ m{t2) 

K{t) = (g) Ki{t2) = {ni . ri2 I ni G , U2 G K2(t2) } 

Notice that in order not to introduce redundant transitions, we only consider 
in the plain s-box a single one of the possible transitions that we can obtain 
by synchronizing (in different order) the same set of transitions. Furthermore, 
those transitions that were in T\ have the same label, rate, numeration and 
conflict as they had in BoXs{Ei). On the other hand, with this construction 
we can obtain in principle infinite nets, as it occurs in PBC, but, taking into 
account that the obtained nets are safe, the arcs having non-unitary weight 
will not enable the corresponding transitions, and thus, these transitions and 
arcs can be removed from the net structure, without affecting its behaviour. 



Finally, we show that given a regular static s-expression E, the operational se- 
mantics of E and the semantics of the corresponding plain s-box are isomorphic. 

Theorem 1. For any regular static s-expression E, the transition system ts{E) 
associated with E, and the reachability graph of the marked SPN {BoXs{E),Me) 
are isomorphic. 

Proof. It is clear that at the functional level we have the same isomorphism as 
in PBC, because we take a total order semantics both in the algebra and in 
s-boxes. Furthermore, the stochastic multiactions obtained in the algebra and 
the corresponding transitions in the plain s-box are labelled with the same rate; 
thus, the transition system ts{E) and the reachability graph of the marked SPN 
{BoXs{E), Me) behave in exactly the same way. □ 



5 A Simple Example: The Producer/Consumer System 

In this section we consider the classical Producer /Consumer system, firstly con- 
sidering a buffer with capacity 1 , and afterwards we will see how to extend the 
specification to a more general case (buffer with capacity n) . 
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Each multiaction a in the specification has associated a delay that follows 
a negative exponential distribution with rate Tq,. There are three different com- 
ponents: P (Producer), C (Consumer) and B (Buffer). The three components 
work in parallel, but they have to synchronize in a set of actions: i (for initiating 
the process), / (for finishing it), s (for storing an item into the buffer) and g 
(for getting an item from the buffer) . The specification of every component is as 
follows. 

Producer: At the beginning, it is ready to initiate the process: < {i}. Tip >. Then, 
it starts a cyclic behaviour consisting of producing an item < {p}, rp >, followed 
by storing the item into the buffer < >. Finally, it ends its execution 

(< {/}, r/p >). This behaviour can be modelled by: 

Producer = [ < {i}, rip > * {< {p}, rp >; < {s}, >) * < {/}, r/p > ] 

Consumer: At the beginning, it is ready to initiate the process: <{i\,ri^ >. 
Then, it starts a cyclic behaviour consisting of getting an item from the buffer 
< {p},rg >, followed by consuming the item < {c},rc >. Finally, it ends its ex- 
ecution (< {/},r/p >). The corresponding specification in sPBC follows: 

Consumer = [ < {*}, > * (< {g}, >; < {c}, rc>)* < {/}, > ] 

The corresponding plain s-boxes are: 

P^P h p2p ti Plc ^5 P2q is P4c 





Buffer :i : we first consider a buffer with capacity 1; the corresponding specifica- 
tion in sPBC is: 

Buffer^ = [ < {i, i}, r,p > *{<s,rs> ; < g, > ) * < {/, /}, r/p > ] 
Finally, the complete specification of the System is: 

System = [ A : ( Producer || Consumer || Buffer i ) ] 
where A = {i,f,s,g}. 

The generalization to a buffer of capacity n (n > 2) is straightforward, we just 
need to change the specification of the buffer as follows: 

Ii= (<s,rj >;<g,r§ >) 

/„ = [<s, Ts > * In-1* <g, >], > 2 

Buffern = [<{*, *}, rip> < {/, /}, r/p > ] 

The corresponding plain s-box for Buffern is shown in Fig. 2. 
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Fig. 2. Plain s-box of BuffeVn 



In this case: 



Systerrin = [ A : ( Producer || Consumer || Buffern ) ] 
where A = {i,f,s,g}. 

6 Conclusions and Future Work 

sPBC is a Markovian extension of PBC which preserves the main features of 
that model. Thus, the syntax of sPBC is a natural stochastic extension of PBC, 
by annotating the multiactions with rates, which represent the parameter of an 
exponential distribution. 

In this paper we have extended the operational and the denotational seman- 
tics that we presented in [14] for finite sPBC, by including the iteration operator, 
and considering the new version for the semantics of the synchronization oper- 
ator, which is inspired in that one presented in [13]. 

The denotational semantics of sPBC is defined using as semantic objects a 
special kind of labelled stochastic Petri nets, called s-boxes. This will be a static 
translation in the sense that the rates of the transitions of the corresponding 
SPNs will not be marking dependent. 

Our work in progress is focused to the definition of a stochastic bisimula- 
tion, which will capture more precisely those processes that can be considered 
equivalent taking into account the stochastic information. Our plans for future 
work include the treatment of the recursion operator, and the inclusion of some 
additional features in the language, such as immediate multiactions. 
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Abstract. In this paper we propose a translation into high level Petri 
nets of a finite fragment of the rr-calculus. Our construction renders in 
a compositional way the control flow aspects present in 7r-calculus pro- 
cess expressions, by adapting the existing graph-theoretic net composi- 
tion operators. Those aspects which are related to term rewriting, as well 
as name binding, are handled through special inscription of places, tran- 
sitions and arcs, together with a suitable choice of the initial marking 
for a compositionally derived high level Petri net. 



1 Introduction 

In recent years, mobility has emerged as a key feature of many complex real 
life computing systems. In order to be able to model such a feature, dedicated 
process algebras have been designed, among which a central role is occupied 
by the 7r-calculus [13]. Within such a formalism, it is possible, for example, 
to model an interaction between a name server and a client willing to access 
a mobile provider known to the server (but not to the client), through which 
the physical address of the provider is acquired enabling a direct access to the 
provider by the client. The basic mechanism facilitating such a dynamic change 
is the ability to pass a reference (or a channel) through a communication on 
a previously known channel, allowing the recipient to use the new channel in 
future interactions. 

The standard presentations of the 7r-calculus are based heavily on term 
rewriting and, as a result, tend to be difficult to translate into automata-based 
formalisms, such as Petri nets, which allow one to specify and reason about the 
causality and concurrency exhibited by a system. The main problem is that the 
standard term rewriting rules change the structure of an expression modelling 
the system, whereas an automata-based representation retains its structure over 
possible evolutions, and the changes of the state are represented explicitly (e.g., 
as net markings). 

In this paper, we outline a compositional translation from the 7r-calculus 
to high-level Petri nets coping with this fundamental problem. Although, for 
brevity, we shall restrict ourselves to the finite fragment of the 7r-calculus without 
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the match and mismatch constructs, the resulting theory is still rich enough to 
allow the description of non-trivial systems. 

2 Finite 7r-Calculus 

We start by briefly recalling the syntax and operational semantics of the tt- 
calculus [13, 15], assuming that C = {a, 6 , c, ...} is a countably inflnite set of 
channels. The concrete syntax of the finite 7r-calculus we use is given below, 
where P denotes an arbitrary agent (or 7r-expression) . 

output /input /internal Prefixes i ::= ab \ ac \ t 

Agents P ::= 0 I £.P \ P + P \ P\P i {uc)P 

The constructs ac.P (input) and {vc)P (restriction) bind the channel c in P, 
and by fn{P) we will denote the free channels of P. Agents are defined up to the 
alpha-conversion of bound channels, implying that the latter may be coherently 
replaced by new channels provided that name clashes are avoided. It is always 
possible to alpha-convert any agent in such a way that each bound channel only 
generates a single binding, and no channel is both free and bound; for instance, 
ab.bb.ba.ab.O can be rewritten as ab.bc.cd.dc.O. 

We will denote by {b/c}P the agent obtained from P by replacing all the free 
occurrences of c by 6 , possibly after alpha-converting P in order to avoid channel 
clashes; for instance, {b / c}dc.cd.O = db.bd.O and {b/c}ab.db.dc.Q = ae.de. db.O. 



Operational Semantics. There are several variants of the operational seman- 
tics of the TT-calculus (see [15]), mainly due to different treatments of the re- 
striction operator, which is generally considered to be the most intricate feature 
of the whole theory. Basically, it is possible to ‘send to the outside world’ a 
restricted channel c through a known channel a, but if c is captured by a receiv- 
ing process then both the sender and receiver become part of an encompassing 
restriction (see the Com rule in table 1). To handle this situation correctly, one 
needs to know which channels are presently ‘known’ to the external environment, 
and which ones are migrating restricted channels. Unfortunately, this may not be 
determined just by looking at a sub-expression without considering its surround- 
ing ‘context’. As a result, we have found it advantageous to use the semantical 
presentation expounded in [6, 7], where the usual transition steps are augmented 
with an explicit information about unrestricted channels. More precisely, we use 
transitions of the form 

AhP >BhQ, 

where £ is a prefix and A, B C C are finite sets of indexing channels. Its intu- 
itive meaning (see [7]) is that ‘in a state where the channels A may be known 
by agent P and by its environment, P can do £ to become agent Q and the 
channels B may be known to Q and its environment’. As a result, Q may know 
more channels than P as an input i = ab adds b provided that b ^ A (intuitively. 
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Table 1. Operational semantics of vr-expressions, where: ns(r) = 0; ns{ab) = ns{ab) = 
the notation A,c stands for the disjoint union A ttJ {c}; and {vc \ A)P is P if 
c £ A and (vc)P otherwise. Symmetric versions of Sum, Par and Com are omitted 



Tan T 

A h T.P > A \- P 



A h ac.P yl U {6} h {b/c}P 



In 





ac , 

A, c h P > A,chP A a A c 


Open 


A h db.P A h P 


ac 

A h (vc)P > A U {c} h P' 


A h P A' h P' 


A, c h P A', c h P' A c ^ ns{£) 


Res 


Ah P|Q A' h P'\Q 


A h (zyc)P A' h (zyc)P' 


A h P A' h P' 


A h P A' h P' A A h Q ^ A" h Q' 


Com 


AhP-tQ A' hP' 


A hP|Q^ Ah (i/c\A)(P'|Q') 



such a & is a new channel communicated by the outside world ~ see the In rule 
in table 1), and an output £ = a b adds b provided b ^ A (intuitively, such a b 
is a channel restricted in P which becomes a new known channel in Q - see the 
Open rule in table 1). We call A\- P a, valid indexed 7r-expression if P is a tt- 
expression and fn{P) C A. Similarly as P, the indexed 7r-expression A\- P will 
also be defined up to alpha-conversion (affecting P but not A). Hence we may 
assume that no bound channel of P is present in A, and that each bound channel 
only generates a single binding; in such a case, a valid indexed 7r-expression will 
be called well-formed. In order to simplify the presentation, we shall often omit 
the trailing O’s in (indexed) 7r-expressions. 

The operational semantics of indexed 7r-expressions is given in table 1 (in [6, 
7], the ‘P h’ parts of the rules are implicit). It preserves the validity of ex- 
pressions and, in combination with renaming and alpha-conversion, also their 
well-formedness. As usual, a complete behaviour of a valid indexed 7r-expression 
P = A \- P (defined up to alpha-conversion) can be represented by a labelled 
transition system (or Its) derived using the rules in table 1 and denoted Its-p. 

In order to achieve a closer correspondence with the Petri net semantics, we 
slightly modify the Sum rule (as well as its symmetric version) into 

, A h P A' h P' 

Sum 

AhP-kQ-^ A'hP'-fO 

This has the advantage of better keeping track of the origin of the move. Indeed, 
if Q = P then a move A h P-\-Q — > A' h P' could well have been derived from an 
application of Sum as well as of its symmetric counterpart. On the other hand, 
a moveP-K3 — ^ A' h P'-l-O clearly arises from Sum', and A h P-fQ — ^ A' h 0-l-P' 
from its symmetric counterpart. We shall need this distinction since, in the Petri 
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net translation of A hP+P, one gets different (though in some sense equivalent) 
markings depending on which of the two translations of P has evolved. The 
above modification is harmless anyway, since we still have in the modified setup 
the standard 7r-calculus rules P + 0 = P = 0 + P. 

A Running Example. We consider a system Dbase modelling a simple 
database composed of a manager Manager = ab.{fg + bc), a file compressing 
process (zipper) GziP = gd.ad, and a memory location Store = {i>h){fe.eh). 
Informally, the manager receives a request for a file on a visible channel a. If 
the file is not available, a negative response is sent back (using a newly acquired 
channel represented by b). Otherwise, the manager initiates a sequence of ac- 
tions, the first being a sending on / to the store of a channel g (previously 
restricted to the manager and zipper processes) allowing a direct access to the 
zipper process. Upon receiving this message, the store uses the now available 
channel g to send a private (signified by the restriction (iz/i)) file h to the zipper 
process. The file is then compressed and forwarded outside on channel a. 

The database system is obtained by putting the three constituent processes 
in parallel as well as restricting the channel g connecting the manager with the 
zipper: 

DBASE = (izg) (M anager | Gzip) | Store . 

In concrete terms, the above scenario consists of the following four stages: 

— The manager receives a request an for a data file from the external envi- 
ronment carrying a channel n which could be used for a negative response: 



{a,c,/} h DBASE > _ QN 

{a,cj,n}'r {vg){fg + nc \ gd.ad) \ {vh){fe.eh) . 

This move has been obtained using the following sequence of rules in table 1: 
In (where a previously unknown channel n is added to the indexing set). Par, 
Res and Par. Notice that the rule In could have been applied with b being 
substituted by any channel from the original indexing set; in such a case, 

ac 

the latter would have remained unchanged, e.g., . . . > {a, c, /} h . . . . 

— The manager can now either reply that the requested data is not available 
(using the fic branch) which is an option our scenario ignores, or initiate 
a positive response (using the other branch), as shown below: 

> {a, c, /, n} h (izm)(0 -|- 0 | md.dd \ {uh){mh)) . (2) 

The above move is more complicated and it is built upon two sub-derivations. 
First, using the rules Out (after alpha-converting the bound channel g to 
a fresh channel m), Sum^, Par and Open, we get: 

- 

{a, c, /, n} h {i^g){{fg + nc) \ gd.ad) > {a, c, /, n, m} h 0 -t- 0 | md.dd . 
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Second, using the rule In followed by Res, we get: 

fm 

{a, c, /, n} h {vh){fe.eh) > {a, c, /, n, m} h {uh){mh) . 

The two derivations are then combined together using the Com rule. This 
exemplifies the scope extrusion which is a key concept of the 7r-calculus. 

— Using the newly acquired restricted channel m, the store transfers the file h 
it held to the zipper: 

> {a, c, /, n} h (izm)(0 + 0 | (uh){ah \ 0)) . (3) 

This is another example of scope extrusion (for the restriction on h) and at 
the same time communication over the restricted channel m. 

— The scenario concludes when the zipper sends off the compressed file to the 
external environment: 

ar 

> {a,c,/,n,r} h (zzm)(0 + 0 I 0 I 0) . (4) 

This step removes the restriction on h and adds r to the indexing set. 



A Context-Based Representation of Indexed tt- T erms. The original syn- 
tactic definition of the 7r-calculus in table 1 is ill-suited for a compositional trans- 
lation into the domain of Petri nets. For example, the scope of the restriction of 
a channel can change dynamically as a result of an application of the Open rule, 
and channels bound by input or restriction can be substituted by fresh ones. We 
address these problems by introducing an auxiliary representation in the form 
of indexed 7r-terms based on the separation of their static features (related to 
control flow) and dynamic features (related to channel substitution and channel 
binding) . 

The signature over which the context based representation is based is slightly 
richer than that of the original syntax. We assume that there are countably 
infinite disjoint sets of: 

— potentially known ehannels C (as in the definition of the 7r-calculus, ranged 
over by the lower case letters, except u and v); 

— potentially restricted channels K (ranged over by the upper case Greek let- 
ters); 

— channel holders H (ranged over by the lower case Greek letters, except c). 

We then represent a well-formed indexed 7r-expression like {&, d} h ba.{i>c)dc.cb.Q 
as a context based expression C = where Ti. = /3a. dy. 7/3.0 is a restriction- 
free agent based solely on channel holders (the identity of the channel holders 
is irrelevant) and c = [/3 i— > 5, 5 i— *■ d, 7 i— > Z\] is a context allowing one to cor- 
rectly interpret the channel holders. From the example we may read that: a 
is presently a channel holder bound by an input (since a is not in the domain 
of the context mapping though is present in the expression 7d); /3 and <5 corre- 
spond respectively to the known channels b and d; and 7 is a channel holder 
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corresponding to the restricted channel A (again, the identity of this restricted 
channel is irrelevant). 

In general, a context is a partial mapping c : El ^ CUK with a finite domain. 
For each <;, we define: 

known{<^) = c(EI) H C (known channels) 

new{<;) = C \ fcnown(c) (potentially known channels) 

rstr(c) = c(EI) n K (restricted channels). 

And the syntax of the context based notation is defined as follows: 

Prefixes p ::= d/3 i a/3 i r 

Agents Ti. ::= 0 i p.Ti. \ Ti + Ti. \ 'H\H 

Expressions C ::= 

A channel holder is bound input if it occurs in the second position of an 
input prefix. A context based expression is well-formed if we have that: all 
the channel holders in 7i are uniquely used (no channel holder may be bound 
by more than one input prefix, and then its other usages are in the suffix of 
this prefix); and no bound input channel holder belongs to dom(c) while all the 
remaining channel holders used in the expression do belong to dom(<f). In the 
following, we shall only consider well-formed expressions. 

It is straightforward to translate a well-formed indexed 7r-expression V = A\- 
P into a corresponding context based one, C = 7i:c. First, for each channel c 
occurring in P and A, we introduce a unique channel holder ac- Then we replace 
each occurrence of c within P by «cj and delete all occurrences of the hiding 
operator, resulting in 7i. The context mapping has as the domain all channel 
holders ac such that c was not input bound in P, and is given by c(o;c) = c 
if c was not restricted, and c(ac) = Ac otherwise (we assume that Ac yf Ad 
for c yf d). E.g., our running example can be rendered in the context-based 
representation as: 

Dbase' = (Manager' | Gzip' | Store') : c 

where Manager' = ap.{^6 (3rj), Gzip' = Scf.acj) and Store' = jK.Rip are 

the three processes expressed in the channel holder notation, and the context 
mapping is given by: 

C=[ai-^a, 71 -^/, rj ^ c , ^ Q\ . 

From the above we can read off the known (indexing) channels, known = 
c(EI) n C = {a, /, c}, and the restricted channels, rstr(c) = <r(EI) n K = {A, 17}. 
Note that there is now no need to represent channel restriction within an ex- 
pression, as in the original syntax, since the relevant information is conveyed by 
the context mapping. 

Later on, we will see how the structure of a holder-based term yields a Petri 
net (with each channel holder being translated into a corresponding place), and 
how the initial marking of these places is derived using the context mapping. 
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3 An Algebra of Nets 

Our target Petri net model, called p-nets, is inspired by the box algebra [2, 3, 
11], designed with the aim of providing a compositional Petri net semantics of 
concurrent programming languages. In this paper, we shall modify the original 
model and, in particular, use coloured tokens together with suitably labelled 
transitions, arcs and read-arcs. The latter are a Petri net specific device allowing 
an arbitrary number of transitions to simultaneously check for the presence of 
a resource stored in a place [8] . 

Transitions in p-nets have three different kinds of labels: 

— UV, Uv and UV to specify communication with the external environment; 

— r to represent an invisible action; 

~ uv and uv to effect synchronous interprocess interactions. 

Places are also labelled in ways reflecting their intended role. Those used to 
model control flow are labelled by their status symbols {internal places by i, and 
interface places by e and x, for entry and exit, respectively); the tokens they hold 
are the standard ‘black’ ones. Holder places carry coloured tokens representing 
channels; in the diagrams, their borders are thick, and they are labelled by the 
elements of H. (A third kind of places will be introduced later on.) 

Referring to figure 1, a holder place can be accessed by directed arcs, which 
can deposit or remove tokens, as well as by read arcs (drawn as thick undirected 
edges), which test for the presence of specific tokens. For example, Nout and Nin 
may be seen as preliminary translations of two context-based expressions, d/3 : c 
and ay : c, where = [a i— > a, /3 6] (note also that Nout and N^n correspond 

to the output and input prefixes, db and ac, of the 7r-calculus) . Furthermore, 
Ncom represents the translation of d/Sjay : c (or db\ac in the 7r-calculus syntax). 
The idea here is to represent a 7r-calculus channel a by a holder place labelled 
a, marked by a token coloured by the actual channel name replacing a. Initially, 
if a is known then the place will contain a single a-token; otherwise it will be 
empty (like the y-labelled place) until a communication or an input prefix inserts 
a channel into it.^ 

In order to observe these mechanisms at work, consider the nets Nout and N^ 
in figure I, each consisting of one transition, two interface places, and two holder 
places. Interface places are connected using the standard Petri net arcs, while 
holder places are connected using directed arcs and read arcs labelled with chan- 
nel variables, u, U, v and V (note that, due to a strict naming discipline, no other 
channel variables will ever be needed). The initial marking on the holder places 

^ It is worth emphasising the importance of using read arcs in the proposed transla- 
tion. In the interleaving semantics, each read arc in nets Nout and Nin could simply 
be replaced by a side loop (two arcs to and from the connected place and transition, 
with the same inscription). However, the transition in Ncom. coming from the syn- 
chronisation of Nout and Nin , would then not be executable because it would require 
two tokens a in the a-labelled place (whereas at most one is available). 
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Fig. 1. Holder places and read arcs 



is derived from the context c which associates, in particular, a and b to the a- 
labelled and / 3 -labelled holder places, respectively. (For control flow places, the 
default initial marking inserts a single black token into each entry place.) 

The annotation of the various arcs by channel variables establishes a binding 
b : {u,U,v,V} C for the channels transferred/tested along arcs adjacent to 
a given transition. The transition of Nin is enabled if the entry place is non- 
empty and there exists a binding b such that the a-labelled place contains at 
least one channel b(u) (in our case, a). The execution of the transition transforms 
the marking in the following way: the black token is removed from the entry 
place and deposited in the exit one; the channel in the a-labelled place is left 
unchanged; and the channel b(u) (e.g., channel e or channel b) is put into the 7- 
labelled holder place. With such a binding b, the firing generates a visible action 
b(M)b(u) (e.g., ae or ab). Similarly, the firing of the transition in Nout generates 
the action db (notice that no other visible action is possible for Nout as any 
binding enabling its only transition must satisfy b(rt) = and b(w) = b). Now, if 
we look at the firing of the T-labelled transition in Ncom, which corresponds to 
the fusion of the two transitions considered previously, the binding with b(w) = e 
is inconsistent with the only binding option for v in Nout (i-e-> b(u) = b), and 
so the internal communication is effected through which the 7-labelled holder 
place acquires the channel b. 

The third, and last, kind of node in a p-net is a special holder place, called 
the tag-place, which is always present (though it may well be disjoint from the 
rest of the net) and is indicated in the diagrams by a double border. The tokens 
stored in this place are coloured and structured by being tagged with a member 
of the set T = {K, N, R}; the place itself is T-labelled. The first tag, K, will be 
used to indicate the channels in known{g). The second tag, N, will be used to 
indicated the new (unknown) channels in new{g). And the third tag, R, will 
be used to indicate the restricted channels in rstr{q). The first case is slightly 
more complicated than the remaining two. For a restricted channel, say A, may 
be present in various holder places, due to synchronisation with various input 
prefixes. Then, if the restricted channel is opened {A becomes a newly known 
channel c), it is not possible to replace Z\ by c in all the relevant holder places 
without some global transformation of the net. Instead, we shall indicate this 
fact by inserting a token c.Z\.K in the tag-place, and then consulting it whenever 
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Fig. 2. Example of the usage of the tag-place in the net Nres 



necessary (i.e., whenever we need to establish whether a restricted channel has 
been opened and what is the corresponding known value). In order to make the 
notation uniform, we shall use tokens a.a.K to denote all those known channels 
which were never restricted. To summarise, a token in the tag-place may be of 
the form: 

— a.N meaning that a is a new channel; 

— Z\.R meaning that Z\ is a restricted channel; 

— a.a.K meaning that a is a known channel (either a has always been known 

or a was initially new and then became known); 

— a.A.K meaning that the restricted channel A has become known as a. 

The arcs adjacent to the tag-place (both directed and read ones) are labelled with 
annotations of the form U.u.K, v.v.K, V.v.K, V.N, ?;.N or ?;.R. For a given binding 
b, such annotations evaluate respectively to b(t/).b(u).K, b(n).b(f).K, b(I^).b(n).K, 
b(F).N, b(ri).N and b(?;).R. Notice that the channel variables (C/, V, u and v) will 
also be used in transition labels. 

Consider the p-net fV^es on the left in figure 2 (only some tokens in the tag- 
place are shown). Such a net gives a translation of a context based expression 
6l(3, assuming that a a and /3 i— > Z\ (in other words, of the 7r-calculus prefix 
ad when d is a restricted channel). The marking in the tag-place indicates that 
Z\ is a restricted channel, n is an unknown channel and a a known one. The 
transition is enabled with the binding b such that b(rt) = b(C/) = a, b(i;) = A 
and b(C) = n. Its execution produces the visible action \>{UV) = an and leads 
to the marking exhibited in the net on the right. This execution illustrates how 
a restricted channel becomes known (which is represented by the insertion of the 
token n.Z\.K in the tag-place), and corresponds to the Open rule in table 1. 

The p-net composition operators that we need are prefixing, N.N', choice 
N + N' , and parallel composition, N\N'. All three operators merge the tag- 
places, as well as the corresponding holder places (i.e., labelled by the same 
channel holder). This corresponds to the asynchronous links used in [11], and 
will allow one to mimic the rewriting mechanism of the standard 7r-calculus. For 
two operand nets, their transitions and control flow places are made disjoint 
before applying a composition operator in order to allow to properly handle the 
cases when, for example, N = N'. 

In the choice composition, the entry places of N and N' are combined, and so 
are their exit places. For example, ‘combining’ the entry places means performing 
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a cartesian product of these two sets, and connecting a new entry place (s, s') to 
a transition t from N (or from N') in the same way as it was connected to s in 
(resp. s' in TV'). This corresponds to the choice operation in the box algebra [3] 
and has the following effect: if we start from the initial marking (i.e., one black 
token is inserted into each entry place), then either N or N' can be executed, 
mimicking the Sum (or Sum') rule and its symmetric counterpart. 

When applying the prefixing operator, there is only one exit place in N 
which is combined with the entry places of N', all the resulting places becoming 
internal. This corresponds to the sequence operator in the box algebra, and the 
effect is that the execution of N after reaching the terminal marking, where the 
only exit place is marked, is followed by that of N' . Such a behaviour mimics 
the Tau, In and Out rules. 

Finally, when composing N and N' in parallel, the p-nets are placed side by 
side and the pairs of transitions labelled uv and uv (one coming from N and 
the other from N') are synchronised, resulting in r-labelled transitions. E.g., in 
figure 1, the net TVcom can be derived as the parallel composition Nout and Nin, 
and the r-labelled transition results from synchronisation of the two transitions 
labelled by uv and uv (which will be wiped out at the end of the translation). 
This, in particular, corresponds to the synchronisation operation in the M-net 
theory [2]. Putting the nets side by side allows to execute both parts in parallel, 
as in the Par rule and its symmetric counterpart, and the synchronisation of 
transition has effect similar to that of the Com rule. 

4 Translating Context-Based Expressions into p-Nets 

Given a context-based expression C = : c, our translation into p-nets is done in 

two phases. First, we compositionally translate Ti. into an unmarked p-net K(7i) 
and then, using the context we fill holder places with appropriate channels, set 
the default initial marking on the control flow places, and delete some transitions 
which are no longer needed. This results in the target p-net denoted by PN(C). 



Phase I The translation K(7f), guided by the syntax tree of H, consists in first 
giving the translation for the basic sub-terms (i.e., 0 and the internal, input and 
output prefixes) shown in figure 3, and then applying p-net operators. 

The basic process 0 is translated into a net consisting of a single entry place, 
a single exit place, and a single tag-place. As a result, we shall have up to 
isomorphism that -|- 0) = K(TV) = K(0 -I- TV), and that K(TV|0) = K(0|TV) 
only differ from K(TV) by two isolated places and so have identical behaviours. 
Hence the standard 7r-calculus rules TV = TV-|-0 = 0-|-TV = TV|0 = 0|TV are also 
observed in the net model. 

The translation of the internal prefix t is very simple as it does not involve 
any manipulation on channels. 



Petri Net Semantics of the Finite rr-Calculus 



319 




Fig. 3. The unmarked p-nets for 0 and the three kinds of prefixes (the tag-place is 
omitted when disconnected) 



Each output prefix a/3, when a ^ /3, is translated into the p-net IK(d/3) which 
may exhibit three kinds of behaviours, corresponding to the firing of three specific 
transitions: 

~ known output. A known channel (matching) V is sent through a channel 
(matching) U. The actual values of U and V are provided by the tokens 
present in the tag-place matching those in the holder places a and /3, ac- 
cessed through u and v. This corresponds to the Out rule. That the channels 
matching U and V are known is determined by the presence in the tag-place 
of tokens tagged with K. Notice that even if the entry place is marked, it may 
happen that this transition is not enabled; this may happen if a (and/or /3) 
is unmarked (it is bound input and the binding prefix has not been executed 
yet), or it is marked by a restricted channel which has not been opened (yet). 
— t": new output. A new channel V is sent through a known channel U. That 
the channels v and V are respectively restricted and new is determined by 
the presence in the tag-place of a channel tagged with R for v, and a channel 
tagged with N for V. After the execution of this transition, the restricted 
channel represented by v becomes known as the channel value of V; this is 
indicated by a token of the form V.vK inserted into the tag-place to replace 
u.R and V/N. This corresponds to the Open rule. Again, this transition may 
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be blocked (possibly temporarily), if a or /3 is unmarked, or if a is marked 
by a restricted and unopened channel, or if [3 is marked by a known or 
previously restricted but now opened channel. 

— communicating output. It is intended to synchronize with a corresponding 
communication input in order to provide the transfer of a channel v through 
the channel u, be it known or restricted. 

The special case of the output prefix aa has a simpler translation, since a may 
not be both known and restricted, so that is unnecessary. Even though the a- 
labelled holder place will never contain more than one token, it is not a problem 
to have two variables on the arcs adjacent to it since these are read arcs, and so 
transitions will be enabled by simply identifying u and v with the same token in 
the a-labelled place. 

For an input prefix a/3, when a ^ (3, the translation is broadly the same as 
for the output prefix. In particular, the known, new and communicating inputs 
should be interpreted in a similar way. Simply, v is now put into (3 instead of 
being read (checked), corresponds to the rule In when b is already known 
(including the case of a previously restricted channel), and to the same rule 
when b is new (it may not be restricted here). In the latter case, the variable V is 
not involved, and the transition is labelled Uv rather than UV . Notice also that, 
for , while v is known as V, it is the possibly restricted original value v which 
is written into /3, and not the corresponding known value V. This is important in 
order to allow subsequent synchronisations between uv with the u coming from 
this place and uv with the u coming from another holder place and containing 
a copy of the original token. Finally, prefixes of the form aa are excluded by the 
well-formedness assumption (no channel holder can be both known and bound 
input). 

For the compound sub-terms, we proceed compositionally: 

K{p.n) = K{p).K{n) 

K{n + w) = K{n) + K{K') 

K(7f I W) = K{H) I K(Tf') . 

As an illustration of this phase of translation, we show in figure 4 the p-net 
obtained for Store'. It is composed of the upper and lower parts corresponding 
respectively to the p-nets for input and output prefixes 'y.K and K.ip (the con- 
catenation with the implicit trailing 0 has been omitted for simplicity without 
changing the essence of the overall picture) . These parts have been composed us- 
ing the prefixing operation which merged the exit place of the first p-net with the 
entry place of the second p-net (leading to an internal place), the holder places 
labelled k from the first and second p-nets as well as their tag-places. The tran- 
sitions labelled uv and uv are intended for synchronisation during subsequent 
parallel compositions and will be deleted in phase II. 

Phase II Having derived K(7i), we construct the target p-net by first removing 
all the transitions labelled by uv and uv, and then inserting one black token into 
each entry place as well as the following channels into holder places: 
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~ <j(q;) into each a-labelled holder place such that a € dom{<;). 

— a.a.K into the tag-place for each a G known{(;). 

— n.N into the tag-place for each n € C \ known{<;). 

— Z\.R into the tag-place for each A G rstr{i;). 

Phase II is illustrated in figure 5 which shows the part of p-net for the 
context-based expression Dbase' : c corresponding to the scenario used in our 
running example (still omitting the trailing O’s). The control-flow places form 
three vertical lines respectively corresponding to the control-flow places of the 
sub-expressions Manager' (on the left), Store' (in the middle) and Gzip' (on 
the right). The r-labelled transitions come from the parallel composition (which 
includes synchronisation) between Manager' and Store' (the upper one) and 
between Store' and Gzip' (the lower one). All the entry places are marked, 
the tag-place and the holder places corresponding to the known or restricted 
channels are marked accordingly to the context 

At the initial marking, the U w-labelled transition may be fired under a bind- 
ing satisfying b(u) = b{U) = a and b(r;) = n since: 

— a is present in a-labelled holder place and a.a.K is present in the tag-place 
(which means that a is a known channel) ; 

— n.N is present in the tag-place, which means that n is an unknown (fresh) 
channel. 

The firing of this transition: 

— consumes • from the input entry place and n.N from the tag-place; 

— generates the visible action an; 
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Fig. 5. The relevant fragment of the p-net resulting from phase II for the running 
example 



— produces a black token in the internal output place, n in the /3-labelled 
holder place and n.n.K in the tag-place (which means that n is now a known 
channel) . 

Next, the firing of the first r-labelled transition is possible. It produces, in 
particular, the restricted A in the K-labelled holder place which implements the 
scope extrusion of the 7r-calculus. 

After that the second r-labelled transition can be fired. It represents the 
transfer of the restricted channel fi between Store' and Gzip' through the 
private (restricted) channel A. It results, in particular, in putting 17 in the (ft- 
labelled holder place. 

At this stage, the firing of the last transition is possible with a binding 
satisfying b'(u) = \>'{U) = a, \>'{v) = 17 and ViV) = r. It generates the visible 
action ar, and replaces 17. R and r.N with r.l7.K inside the tag-place. This means 
that 17 is not longer restricted and that r has became known. 



Main Result. It turns out that the proposed translation is sound, in a rather 
strict sense, which is expressed by the following theorem, the proof of which may 
be found in the technical report version of this paper [9]. 
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Theorem. For every indexed tt- expression V , its labelled transition system 
Its-p (eonsidered up to alpha- conversion) is isomorphic to the labelled transition 
system ItSpN(c) of the p-net PN(C), where C is any well-formed context based 
expression corresponding to V. 



5 Related Work 

A first paper dedicated to giving a Petri net semantics for the 7r-calculus appears 
to be [10]. However, it only considers the so-called ‘small’ 7r-calculus (without 
the choice composition) provided with the reduction semantics (addressing only 
the communications between parallel components). Due to these limited aims, 
the problem is greatly simplified as restrictions may be managed syntactically 
(in fact, eliminated by renaming the restricted channels by fresh ones). 

While not based on nets, [4] already considers the causality structures of 
the TT-calculus, and distinguishes structural and link dependencies (the former 
mainly due to prefixing and communications, and the latter due to extrusion). 
However, the authors only capture the first kind of causality in their semantic 
model, while we taken both of them into account. 

A graph-rewriting system is proposed in [14] as a semantic model for a rather 
restricted fragment of the 7r-calculus. This approach mainly addresses the con- 
currency feature of systems whereas we concentrated here on their interleaving 
semantics, since our aim was to show that our translation leads to nets with the 
same sequential behaviour as that defined by the standard interleaving semantics 
of the TT-calculus. One of our immediate goal is to look at concurrency issues, and 
in this respect we may notice a fundamental discrepancy between our approach 
and [14] in the handling of restriction. More precisely, [14] allows parallel open- 
ing for expressions like {iyy){xy\P\zy) by letting the actions xy and zy to occur 
independently (in parallel), while in our approach they must in some sense agree 
on their common exportation, so that only one of them (chosen arbitrarily) is in 
fact an opening, the other one accepting the choice already made. 

The most frequently cited translation of 7r-terms into Petri nets is proba- 
bly [5], which uses (low-level) labelled Petri nets extended with inhibitor arcs, 
while we use high-level nets with read-arcs. Moreover, the way compositional- 
ity is obtained is different from that used in our approach. Indeed, the approach 
from [5] proceeds by first establishing a general infrastructure, with places corre- 
sponding to all the possible sequential 7r-terms decorated with some conflicting 
set, and to all possible restrictions and conflicts, with all possible transitions 
between those places. It then defines compositionally the initial marking cor- 
responding to each 7r-term (here, guarded recursions are allowed). As a conse- 
quence, even for a very simple process expression r.O, this leads to a net with 
infinitely many places and transitions (but only a single token in a single place) . 
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6 Conclusions 

In this paper, we outlined a Petri net based translation of the finite 7r-calculus, 
as well as an intermediate process algebra. Both approaches are based on the 
notions of a channel holder and context. Our development has been motivated by 
a desire to provide a compositional translation of the original 7r-calculus to the 
domain of automata-based models of computation (in particular, Petri nets). 
We therefore needed to address problems relating to the fact that a number 
of fundamental features of the former are based on purely language theoretic 
concepts (such as alpha-conversion and channel restriction). One of possible 
practical applications of our translation will be in making it possible to use 
Petri net based verification techniques to prove properties of mobility systems. 

We now plan to investigate the extension of the theory to infinite behaviours 
through replication or recursion, as in the full 7r-calculus, or through iteration, 
as in the box algebra. 
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Abstract. Monitoring large distributed concurrent systems is a chal- 
lenging task. In this paper we formulate (model-based) diagnosis by 
means of hidden state history reconstruction, from event (e.g. alarm) ob- 
servations. We follow a so-called true concurrency approach: the model 
defines explicitly the causal and concurrency relations between the ob- 
servable events, produced by the system under supervision on different 
points of observation. The problem is to compute on-the-fly the different 
partial order histories, which are the possible explanations of the observ- 
able events. In this paper we extend our first method based on Petri 
nets unfolding to high-level parameterized Petri nets. This allows the 
designer to model data aspects (even on infinite domains) and non de- 
terministic actions. The observation of such an action gives only partial 
information and the supervisor has to introduce parameters to represent 
the hidden aspects of the reached state. This supposes that the possible 
values for the parameters are symbolically computed and refined during 
supervision. In practice, non deterministic actions can also be used as an 
approximation to deal with incomplete information about the system. In 
this case the refinement of the parameters during supervision improves 
the knowledge of the model. 



1 Introduction 

Concurrent and distributed systems have been at the heart of computer science 
and engineering for decades. Formal models and mathematical theories of con- 
current systems have been essential to the development of languages, formalisms, 
and validation techniques that are needed for a correct design of large distributed 
applications. 

In this paper, we consider another instance of the use of formal models to 
master the complexity of distributed applications, namely the problem of infer- 
ring, from measurements, the hidden internal state of a distributed and asyn- 
chronous system. An important application is distributed alarm correlation and 
fault diagnosis in telecommunications networks, which motivated this work. 

* This work was supported by the French RNRT project SWAN, funded by the Min- 
istere de la Recherche; partners of the project are Inria, France Telecom R&D, Alca- 
tel, QosMetrics, and Paris-Nord University. 
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The problem of recovering state histories from observations is pervasive 
throughout the general area of information technologies. For instance, estimating 
the state trajectory from noisy measurements is central in control engineering, 
with the Kalman filter as its most popular instance [8]; the same problem is con- 
sidered in the area of pattern recognition, for stochastic finite state automata, in 
the theory of Hidden Markov Models [13]. For both cases, however, no extension 
exists to handle distributed systems. Finally, fault diagnosis in discrete event 
systems (e.g., automata) has been extensively studied [2, 15], but the problem 
of dealing with concurrent model is just starting. 

We follow a so-called true concurrency approach: the model defines explicitly 
the causal and concurrency relations between the observable events, produced 
by the system under supervision on different points of observation. The prob- 
lem is to compute on-the-fly the different partial order histories, which are the 
possible explanations of the observable events. A natural candidate to formal- 
ize the approach are 1-safe Petri nets with branching processes and unfoldings. 
The previous work of our group used this framework to define the histories and 
a distributed algorithm to build them as a collection of consistent local views [1]. 

In this paper we extend our method to high-level parameterized Petri nets. 
This allows the designer to model data aspects (even on infinite domains) and 
non deterministic actions. The observation of such an action gives only partial 
information and the supervisor has to introduce parameters to represent the 
hidden aspects of the reached state. This supposes that the possible values for 
the parameters are symbolically computed and refined during supervision. In 
practice, non deterministic actions can also be used as an approximation to deal 
with incomplete information about the system. In this case the refinement of 
the parameters during supervision improves the knowledge of the model. We 
think this symbolic approach will be able to deal with more complex distributed 
systems. At the heart of our scientific contribution is the definition of a symbolic 
unfolding for high-level Petri nets, which combines the traditional unfolding [10, 
11] with a kind of a-conversion (A-calculus) to deal with parameters. Up to 
our knowledge, this is original. The idea of using an unknown symbolic initial 
marking has already been addressed in [16], but restricted to the framework of 
simple Petri nets and their marking graphs. 

This paper is organized as follows. We first begin in Section 2 by an informal 
presentation of the problem on a toy example, illustrating the high-level Petri 
net model we use, its unfolding and the trajectories we want to compute with 
respect to a given partially ordered observation. The mathematical background 
is recalled in Section 3, following the usual notation for Petri nets, as used for 
instance in [10]. In Section 4, we present an original algorithm to compute a 
symbolic unfolding. This allows us to formally express the diagnosis problem, 
which is done in Section 5 using a composition between the observation and the 
model, which can be then symbolically unfolded. We also show that unfolding 
can be performed on-the-fly, observable event by observable event. We conclude 
in Section 6 by presenting different perspectives on the use of the approach to 
monitor real distributed systems. 



328 



Thomas Chatain and Claude Jard 



2 An Example of Diagnosis Under Partial Observation 

2.1 The Parameterized Concurrent Model 

Our parameterized concurrent model is based on the standard high-level Petri 
net introduced in [9] and augmented with free variables. It is exemplified in Fig- 
ure 1, which shows two interacting components, named A and B. Component 
A may fail (observed as a) with a given non observable severity level (param- 
eter 1). To be completely repaired, component A must execute a local action 
(observed as p, and possible only if the severity level is less than 10 ), and wait 
for the completion of the recovery procedure of component B, which has been 
informed of the failure. To recover from a failure of severity I, component B 
must execute I repairs, observed as 7 . But, at any time, component B may also 
fail and stop (observed as (3) . The initial transition _L starts the system in feed- 
ing the places 1 and 2 with black tokens (transported by the local variable m). 
Component A has two private states: safe, represented by place 1, and faulty, rep- 
resented by place 3. Upon entering its faulty state, component A emits an alarm 
a. The failure of component A causes repairing actions in component B. This 
causality is modeled by the shared place 4. The monitoring system of component 
B (sensor B) only detects that component B provides an elementary action of 
repairing (observed as 7 ). The last action recovers the fail by putting the system 
again in state 2, shared with component A. This action is not observable. 

All the observable events are also called alarms in the sequel, and represented 
by a grek letter on the figures. The fact that a transition is not observable is 
shown by writing e instead of an alarm. It is to be noticed that the exact severity 
level of the fail I is not observable, and will be inferred during supervision using 
a kind of symbolic execution of the model. 

In order to define the dynamics of such network, we consider that each place 
can be fed by a multiset of values (often called “colors” ) . These values are tested 
and forwarded by the transitions. As we can see, each transition associates a label 
{a, P, 7 , p, e) and a predicate (printed near the transition in a curly brace, as 
a conjunction of expressions), called the guard. Furthermore, each incident edge 
is labeled by a local variable. The transition guard is composed with these local 
free variables. Informally, a transition is fireable if its guard is satisfiable. This 
means there exist some values to the variables for which the guard is true. One 
can thus select an instance of these values, which are unified (matched) to the 
variables. It is required that the values unified to the input arcs variables are 
present in the input places. The firing of the transition removes these values 
from the input places. The output places are then filled by the values unified to 
the output arc variables. In our example, the firing of the transition _L puts one 
token in places 1 and 2. The transition labeled by a becomes fireable. When it 
fires, it removes the tokens from 1 and 2 and puts a token in place 3 and an 
arbitrary integer I (provided / > 0) in place 4. The dynamics is formally defined 
in Section 3. 
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Fig. 1. A concurrent machine with two components, which may fail with an unknown 
severity level and can be repaired accordingly 



2.2 Supervision Architecture 

We consider the following setup for diagnosis, assuming that messages are not 
lost. Each sensor records its local alarms in sequence, while respecting causal- 
ity (i.e. the observed sequence cannot contradict the causalities defined in the 
model). The different sensors perform independently and asynchronously, and 
a single supervisor collects the records from the different sensors. Thus any in- 
terleaving of the records from different sensors is possible, and causalities among 
alarms from different sensors are lost. This architecture is illustrated in Figure 2. 

For the development of the example, we consider that the system under 
supervision produces the sequences a pa on sensor A, and 7/3 on sensor B. 

We think such an architecture is the first important step towards a dis- 
tributed supervision, in which the monitoring is itself distributed, with different 
supervisors cooperating asynchronously. Each supervisor is attached to a sensor 
(i.e. a component of the model), records its local alarms in sequence, and can 
exchange supervision messages with the other supervisors, asynchronously. This 
aspect is deferred to a subsequent paper. 
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System under supervision 



Fig. 2. The considered supervision architecture, composed of several sensors that 
report alarms asynchronously to a unique diagnoser 



2.3 Unfoldings: An Efficient Data Structure to Represent All Runs 

The construction of the runs of the high-level parameterized Petri net of Figure 1 
is illustrated in Figure 3. 

The algorithm is to consider all the transitions of the original Petri net, and to 
place them, one at a time, if they are possible. Let us start by placing the initial 
transition T. Once placed, a transition becomes a unique event (denoted by 
T, tti. Cl etc.) in the graph. The local variables acquire then the status of global 
variables and for this purpose are renamed (actually indexed by the event name). 
An event e, instance of a transition t, is placed only if its preset (the input places) 
is present in the graph and if the following enabling condition is satisfiable. The 
enabling condition is formed by the conjunction of the local conditions of the 
events located in the causal past of e (see below the definition of causality) and 
of its local condition. The local condition is the guard of the transition t (in 
which the local variables have been renamed by their global names), augmented 
with the constraint that the variables of the input arcs have the same values that 
the variables of the output arcs of the input event of the input places, in order to 
capture the causal relation. To keep track of this condition, we associate a new 
predicate with the new event. In the graph of Figure 3, the local condition of each 
event is printed in a curly brace. This graph is usually infinite. We have drawn 
only a prefix of it. In the formal description of Section 4, the local condition is 
the predicate loc-pred{e) and the enabling condition is the predicate pred{e). 

Two events linked by a path of the graph are causally related, since there 
exists a flow of values between them. Two events are concurrent if they are 
causally related and if they are not in conflict (i.e. cannot belong to a same 
run). There are two causes of conflict. The first one, called structural conflict is 
that they have been separated by a choice in the system, represented in the graph 
by a branching from an ancestor place of these events. The second possibility 
is specific to the parameterized model: two events are also in conflict (called 
non- structural conflict) if their predicates are not simultaneously satisfiable. We 
thus show that the symbolic unfolding is an interesting structure to represent 
the different runs, in which causality and concurrency are explicitly given. The 
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different runs are superimposed in the graph and separated by the notion of 
conflict. In Figure 3, the event r is a cause of event the event ei is concurrent 
with event r; event 02 is structurally in conflict with event e^. A non-structural 
conflict is also possible between the event r and an event labeled by 7 reachable 
after more than 10 consecutive repairs on component B (not represented in the 
prefix chosen in the figure) . 

2.4 Asynchronous Diagnosis 

Figure 3 showed different runs of the system, represented in a single graph. The 
question now is to select the runs that are compatible with the observations. In 




Fig. 3. Some runs of the example represented in a branching process 



332 



Thomas Chatain and Claude Jard 



Figure 4, we have projected the graph of Figure 3 by considering that some events 
are not compatible with the actual observation. This is the case for instance for 
the first (3 transitions, which cannot be considered since 7 have to be explained 
before and that the occurrence of j3 stops the production of 7 in the model. The 
resulting graph shows two possible explanations: the first corresponds to the left 
part of the graph with the following partial order a.{p || e).a.j.P; the second 
is the right part of the graph: a.{p || {'j.€)).a.p. We see that these two possible 
explanations share a same prefix a.p in the graph. Another interesting fact is 
the refinement of constraints on variables during the unfolding: for instance, at 
the end of the first explanation, we can infer that the severity level of the first 
fail a was 0, because of the conjunction of the predicates of the events a\ and e\. 

In practice, the desired projection is obtained by synchronizing the system 
model with the observations. This augmented model is then unfolded. The last 
phase is to keep only the system part of the unfolding to present the explanations 
to the user. Figure 5 shows our original model, constrained with the considered 
observations. The sequencing of local observations are represented as the linear 
nets at the left and right parts of the figure. The observations constrain the 
execution of the original model since the treatment of the next local observation 
requires that a transition with the same label in the model has been fired. This 
is the role of places A, B, and their complements A and B in the figure. 

The rest of the paper defines mathematically these different objects and 
operations. The final contribution is an on-the-fly algorithm, which builds the 
different possible explanations in the form of an unfolding, increasing step by 
step at each observation. 

3 Mathematical Background: High-Level Petri Nets 

Basic references are [2, 4, 14]. We use the standard notations, adopted from [10]. 



3.1 Notations 

We recall the notations: 

— f : A I — > B denotes a mapping / from A to B; 

— A l±l B denotes the disjoint union of the sets A and B\ 

— e[n <— n'\ is the expression e in which all the occurrences of the name n have 
been replaced by the expression n' . 

e[n ^ /(n)]„g N is the result of the parallel replacement of each name n G N 
by the expression f(n). 

A multiset over a set A is a mapping p, : X 1 — > N. We denote x G p it 
p{x) > 0. We define the empty multiset 0 as %{x) = 0 for all x G X. We define 
the union of two multisets p\ and p2 over X as {p\ + P2){x) Pi{x) + P2{x) for 
all X G X. For two multisets p and p' over X, we write p < p' it for all x G X, 
p{x) < p'{x). A multiset p is finite if {x G A j x G /r} is finite. In this case 
we can represent it with {]...[} delimiters. For example {ja, a, foj} will denote the 
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multiset /i defined by fi{a) = 2, /i(6) = 1 and fi{x) = 0 for all a: € X \ {a,b}. 
For a mapping h : X i — > Y, we denote {\h{x) | x G ^|} or h{fi) the multiset fi' 
over Y such that for all y GY, y,'{y) = E /i(x) . 

x£XAh{x)—y 




Fig. 4. The causal graph resulting of our diagnosis algorithm 







334 



Thomas Chatain and Claude Jard 



3.2 High-Level Petri Nets 

In this section we present the formal model we use to represent the system we 
work on and its behavior. The example of Figure 1 illustrates this model. 



II 


II 


II 


1m = • 


1m = • 


1 m = • 




Fig. 5. The model of Figure 1, constrained by the observation 



Symbolic Diagnosis of Partially Observable Concurrent Systems 335 



It is assumed that there exists a (finite or infinite) set Tok of elements (or 
‘colors’) ^ and a set VAR of variable names, such that Tok n VAR = 0 . 

A high-level Petri net is a quadruple N = (P, T, W, i) such that: 

— P and T are disjoint sets of places and transitions respectively; 

— W is a, multiset over (P x VAR x P) U (P x VAR x P) of arcs; 

— b maps each t S P to a predicate i{t) on VAR{t), where VAR{t) = {n | 
(p, n, f) S hP V (t, v,p) G VP}. For every t €T, i(t) is called the guard of t. 

For two nodes y,y' & PUT, we denote 1/ — *■ p' if there exists a variable v such that 
{y,v,y') G W. The reflexive and irreflexive transitive closures of — > are denoted 
respectively by ^ and For a transition f G P, let *t = {|(p, v) \ {p, v, t) G VF||, 
P = {\{p,v) I (t,v,p) G VV^Ij. 

In figures, places are usually represented by circles and transitions by squares. 
Labeled arrows between places and transitions represent the arcs. The guards of 
the transitions are printed in a curly brace. 

A homomorphism from a high-level Petri net N = (P, P, VF, i) to a high- 
level Petri net N' = {P' ,T' ,W ,i') is a mapping h ■. PUT 1 — > P' U T' such 
that: 

— h{P) C P' and h{T) C P'; 

(•h{t) = {|(/i(p),u) I (p,v) G *t[l- 

— for all t G P, < h{ty = {|(/i(p),u) | {p,v) G P} 

[d{h{t)) = i{t) 

A firing mode of a transition t is a mapping a : VAR(t) 1 — > Tok such 
that b{t) evaluates to true under the substitution given by a. We denote 
*(^W) = {\{p,cr{v)) I {p,v) G 'til and {t,a)* = {|(p,ct(u)) | (p,v) G P}. 

A marking of a net W is a multiset over P x Tok. A transition t is enabled at 
marking M with firing mode a if *(f, tr) < M . Such a transition can fire, leading 
to a new marking M' = M — *(t, a) {t, cr)*. 

A high-level Petri net system is a high-level Petri net T '= (P, T, W, l), which 
has a unique initial transition called T such that *T = 0 . In the sequel we assume 
that t(T) is satisfiable, i.e. T has at least one firing mode. T fires only once, at 
the empty marking, to start the system. 

Remark: low-level Petri nets can be seen as particular high-level Petri nets, in 
which all the arcs use the same variable m, and all the guards are (m = •). 
The drawback with low-level Petri nets is the lack of manipulations of data. 
In practice, the data aspects have to be enumerated, and thus explode and are 
limited to finite domains for variables. This is why we consider the extension to 
the so-called high-level Petri nets. 

^ We do not mention any type conditions on the colors because this is not essential 
for our application. Adding types would only be a refinement of the firing conditions 
of the transitions. 
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4 Symbolic Unfolding 

This section formally defines the structure we use to represent the different 
runs of a system. Figure 3 shows a symbolic branching process of the system of 
Figure 1. For each event e, the predicate loc-pred{e) is printed near the event. 



4.1 High-Level Occurrence Nets 

The net N (P, T, W, l) is called ordinary if for each pair y, y' of nodes of iV, 
there exists at most one arc connecting y and y' var W{{y,v,y')) < 1). 

Two nodes (places or transitions), y and y' , of an ordinary net N= (P, P, W, l) 
are in structural conflict, denoted by yffy', if there exist distinct transitions 
t,t' €T and a place p € P such that p^t, p^t',t<y and t' ^ y' . A node y 
is in structural self-conflict if yffy. 

A high-level occurrence net is an ordinary net system ON (B, E,G, l), 
where P is a set of conditions (places), P is a set of events (transitions) and G 
is a flow relation, satisfying the following conditions: 



— for every b € B, there exists a unique pair (e, v) called *b such that (e, v, b) G 

G; 



— for every y G B U E, 



^{y#y) 

^{y < y) 

-L ^ y 

there are finitely many y' such that y' ^ y. 



-< is called the causality relation. We say that node y is causally related to 
node y' if y ^ y' . 

For all e G P we denote [e] {/ G P | / ^ e}. For all P C P we denote 

= U/GFm- 

For a high-level occurrence net ON = {B,E,G,l) we define the mappings 
loc-pred and pred which map each e G P to the predicates 



loc.pred{e) = L{e)[v ^ Ve]v^vAR{e) 

A j\^ (t>e = fy/) with *& = (e', fy) 

{h,v)^*e 

pred{e) = loc-pred{f) 

f<e 



4.2 Symbolic Branching Processes 

A symbolic branching process of T is a pair tt {ON, h) such that: 

— ON is a high-level occurrence net such that for all e G P, pred{e) is satisfiable; 

— /i is a homomorphism from ON to T ; 

— M^) = A; 

— for all e, / G P, if h{e) = h{f) and *e = */, then e = /. 
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4.3 Non Structural Conflict, Concurrency 

In branching processes of high-level Petri nets, the causality relation is the same 
as in branching processes of low-level Petri nets. But there are two different 
causes of conflict. The structural conflict is the equivalent of the conflict relation 
in branching processes of low-level Petri nets; and we define a non structural 
conflict, that restricts the concurrency relation. This notion of non structural 
conflict is due to the existence of symbolic parameters. 

The events of the set F C E are in non structural conflict if A/gf is 

not satisflable. We note that for all F in non structural conflict and F' C E, if 
\F~\ C [f'] then E' is also in non structural conflict. 

The events of F are in minimal non structural conflict if there does not exist 
any F' C E such that [F'] C [F] and the events of F' are in non structural 
conflict. 

The events of the set F C F are concurrent if they are not in non structural 
conflict, and for each e, e' S F, neither e ^ e' , nor e! -< e, nor efl^e! holds. 
We extend the notion of concurrency to conditions: a set C of conditions are 
concurrent if the events of the set {e G E \ 3b G C e ^ b} are concurrent. 

A co-set is a set of concurrent conditions. A configuration is a set of events 
E C E whose elements are not in non structural conflict, and which is conflict- 
free (for all e,f G F, ^(e#/)) and causally closed (for all / G F and e G E, 
e f implies e G F). 

4.4 Symbolic Unfolding 

The set of all symbolic branching processes of a high-level Petri net system is 
uniquely defined, up to an isomorphism (i.e. a renaming of the conditions and 
events), and we shall not distinguish isomorphic branching processes. For tt, tt' 
two symbolic branching processes, F is a prefix of tt, written tt' CI tt, if there 
exists an injective homomorphism (j) from tt' into tt, such that <()(T) = T, and the 
composition ho (j) coincides with h' , where o denotes the composition of maps. 

Thus, the notion of unfolding of a Petri net as the unique maximum branch- 
ing process up to isomorphism, proved in theorem 23 of [3], can be adapted 
to symbolic branching processes of high-level Petri nets to define the symbolic 
unfolding Ur of a high-level Petri net system T. 

Branching processes of a (high-level) Petri net represent the different runs. 
The interest is that the causalities and the concurrency between the transitions 
figuring in the run are explicitly represented in a graph. This is why, this kind 
of behavioral semantics for Petri nets is called “true concurrency semantics”, 
and fits particularly well with the kind of trajectories we want to produce as the 
monitoring activity. 

Some applications use the notion of finite complete prefix defined on low- 
level Petri nets. We do not need this notion in the area of diagnosis because the 
unfoldings we generate are finite, as the model is constrained by the observation. 
Furthermore we think that it would not be obvious to define a notion of finite 
complete prefix for symbolic unfoldings of high-level Petri nets, because of the 
theoretical power of the model. 
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4.5 Algorithm 

We propose an algorithm to compute the symbolic unfolding of a high-level Petri 
net. This algorithm needs to decide if the predicates pred{e) are satisfiable. This 
is possible if the guards of the transitions are expressed in some weak enough 
language. One possible framework is the use of Presburger arithmetics [12] (arith- 
metics without multiplication). 

The algorithm consists in a non deterministic iteration, after the placement 
of the initial event T. In each iteration we choose a transition t and a co-set C 
to create a new event e. The predicate pred{e) is memorized for each event. The 
minimal non structural conflicts are memorized in the variable conflict, which is 
used to find the co-sets. 



Initialization 

1. initialize the sets B,E,G to 0, h and pred to the empty mapping 
and conflict to 0; 

2. add the event T to E, and update h with h{J-) = T; 

3. for each {p, v) G T*, add a new condition b to B, add (T, v, b) to G 
and update h with h{b) = p; 

4. extend pred with pred{l.) = (-(T)[u <— 

Non deterministic iteration 

Repeat until no transition can be chosen: 

1. choose nondeterministically a transition t G T\ {T} such that there 
exist a co-set G and a bijection pin from *t to G, satisfying: 

— for all (p,v) G *t, h(pin((p, v))) = p] 

— the predicate pred-C loc-pred A pred{b) is satisfiable, 

where: 

• pred{b) = pred{e') with *6 = {e',v') 

• l0C.pred= i{t)[v ^ Ve]vaVAR(t) 

A !\ (ue = u'/) With ' pin{{p,v)) = {e' ,v') 

{p,v)e't 

• e is a new event. 

2. add the event e to E, and update h with h{e) = t; 

3. for each {p,v) G *t, add {pin{{p,v)),v,e) to G; 

4. for each (p,v) G t* , add a new condition h to B, add (e,v,b) to G 
and update h with h{b) = p; 

5. extend pred with pred{e) = pred-e; 

6. extend conflict with the newly created minimal non structural con- 
flicts, if any. 



In the area of diagnosis, the net is constrained by the observation as we will 
see in Section 5. Thus its unfolding is finite and the algorithm terminates, if 
we except models that contain loops of non observable transitions. But in the 
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general case the unfolding may be infinite, and precautions have to be taken to 
ensure that all the events of the unfolding are computed. One method is to use 
the causal depth of the events defined as follows: the causal depth of an event 
e G if is the number of events on the longest path from _L to e. For all integer n, 
the number of events at depth n is finite. If the algorithm is forced to compute 
all the events at depth n before those at depth n + 1, then all the events will be 
computed. 

5 Symbolic Diagnosis: Formal Problem Setting 

5.1 Observations 

Observations and their impact on the original system model are represented by 
adding new places and transitions in the high-level Petri net. 

A sensor is a place s of a high-level Petri net that has no output arc and at 
most one input arc from each transition t S T. To simplify the notations, we 
assume that the variable associated with this arc is always A^. When a transition 
t G T fires, the value taken by A^, is called the alarm. 

A local observation sequence from the sensor s is a finite sequence of alarms 
(As,i, . . . , -\s,us)- A global observation from a set S of sensors is a mapping A from 
sensors s G S' to observation sequences (A^^, . . . , As,„J. Consider two observa- 
tions A and A', which associate with each sensor s G S, the observation sequences 
(As,i, . . . , Xs,ris) and (A^ j, . . . , A',, „,) respectively. We say that A is a prefix of A', 
written A < A', if for all s G S, Us < n'^ and (A^p, . . . , Xs^nfi = (^s i; • ■ • ) nj- 

5.2 Diagnosis Net T>(N, A) 

In this section we show how to build a net T>{N, A) from a net N modeling 
a system and an observation A of this system. The idea is to constrain the 
model so that each transition of the model that sends an alarm to a sensor s 
is not allowed to fire until all the previous alarms sent to s have been treated. 
To achieve this we create a new place s, add an arc from s to each transition 
that sends an alarm to s, and ensure that s contains a token if and only if all 
the alarms sent to s have been treated. The treatment of the alarms received by 
sensor s is modeled by a set of new transitions i = 1, ... ,Us (one for each 
observation) . Transition tg,i guarantees that the alarm received by s matches 
the observation Xg,i. Once the alarm is treated, puts a token in the place 
s, which allows the transitions of the model to emit new alarms. The formal 
definition of V{N,A) follows. 

For a net N = (Pat, Tjv, Wn, i.n) and an observation A from a set S of sensors 
of N, we define the net V{N,A) = (P, T, W, i), called net N observed as A, as 
follows (we assume that m is a fresh variable name): 

- P = PjY 1+1 {s I s g S'} 1+1 j I s G S', i = 0, . . . , Us} 

“ T = Tn'S {ts,i I s G S, 1=1,..., Us} 
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- W = Wjv + {l(-L,rn,s),(±,m,Ps,o) I s G S’!} 

+ {\{s,m,t)\s€SA {t, Xs, s) € Wn'^ 

{1(^7 5 S^i-! 5)|5C5*, i — 

+ {\{ps,i-i,m, m,ps,i) I s G S', i = 1, . . . , ns[l- 

— i(t) tAr(i) A (to = •) if i € T/v 

t(is.i) (As = Xs,i) A (to = •) for all s G S, * = 1, . . . , rij 

Figure 5 shows the net of Figure 3 observed as a, p, a from sensor A and 7 , (3 

from sensor B. 



Remark. For two observations A and A' such that A < A' , T>{N, A) is a subnet 
of T>{N^ A'). Indeed T>{N, A') can be built from T>{N, A) by adding the places and 
transitions required by the new alarms, and arcs connecting the new transitions. 
No new arc is added to the old transitions. That is why every execution of the 
net V{N,A) is also a valid execution of V{N,A'). 



5.3 Global Diagnosis 

We call diagnosis of observation A on net N the symbolic unfolding Ux>(n,a) of 
the net N observed as A. For each set F C if of concurrent events such that the 
restriction of /i to F is a bijection from F to {ts,n, | s G F}, the configuration 
[F] explains the observation A. 

We may want to get rid of the causalities due to the observation. For this 
purpose, we remove all the events and conditions corresponding to the sensors or 
to the observation. This operation, called projection on N removes the causalities 
due to the observation. But we must keep the information of the (structural and 
non structural) conflicts due to the observation, that do not appear any more in 
the projected net. 

Figure 4 shows all the possible explanations of the example of Figure 3. 



On-the-Fly Computation. The unfolding of T>{N, A) can be computed by 
the algorithm of Section 4.5. Moreover, we can adapt this algorithm in order to 
compute on-the-fly the partial order histories that explain the observed alarms. 
Indeed, if A and A are two observations such that A is a prefix of A', then, con- 
secutively to the final remark of Section 5.2, each branching process of F(iV, A) 
is also a branching process of T){N,A). Then we can compute on-the-fly the 
explanations by updating T>{N, A) each time a new alarm is observed. After this 
modification is done, the algorithm will continue and compute the explanations 
of the new observation. 

6 Conclusion 

We have presented a possible approach to the supervision/diagnosis of dis- 
tributed systems, in which the explanations are given by a family of partial 
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orders on the observable events, represented by an unfolding graph. The main 
contribution of the paper is to consider parameters in the model. These param- 
eters are used to model incomplete information on the system under supervision 
(i.e. partially observed). We think it is an important aspect to deal with real 
contexts. We have different perspectives. From the practical point of view, we 
are starting the implementation of the algorithm. The main extension we plan 
is to deal with a distributed supervision architecture; that is extend the ap- 
proach presented in [7] to the symbolic framework we consider. An other work 
in progress is to study time Petri nets as a particular case of our parameter- 
ized model. The variables of the model are used to model the different instant 
of transition firings. This will define a new notion of unfolding for time Petri 
nets, which keeps concurrency. More generally, because of the “local” property 
of the unfolding algorithm, we think our approach could be extended to deal 
with dynamic systems, in which the model can evolve during observation. 
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Abstract. Numerous specialized ad hoc routing protocols are currently 
proposed for use, or being implemented. Few of them have been sub- 
jected to formal verification. This paper evaluates two model checking 
tools, SPIN and UPPAAL, using the verification of the Lightweight Un- 
derlay Network Ad hoc Routing protocol (LUNAR) as a case study. 
Insights are reported in terms of identifying important modeling consid- 
erations and the types of ad hoc protocol properties that can realistically 
be verified. 

Keywords: Mobile ad hoc networks, routing protocols, formal verifi- 
cation, model checking, SPIN, UPPAAL, LUNAR 



1 Introduction 

Mobile ad hoc networks (MANETS) require efficient and correct routing proto- 
cols. So far they have mainly been evaluated by simulation and live testing, and 
most of the formal verifications have involved a significant amount of user inter- 
vention. We here consider a completely automatic verification strategy where the 
user specifies the protocol in a high level formalism and provides some general 
properties. These are given to a tool which will output a pass or fail answer to 
questions regarding key protocol properties, without involving the user in addi- 
tional interaction. Compared to interactive methods much is gained in ease of 
use for non experts. With this intent we evaluate two model checking tools, SPIN 
and UPPAAL. This enables us to analyze the modeling constraints that have 
to be imposed, and also to provide a comparison of the tools and their suitabil- 
ity for the verification of ad hoc routing protocols. The evaluation additionally 
provides a good starting point for further work on infinite-state verification. 

A MANET (Figure 1), is a spontaneous network of computers which com- 
municate over a wireless medium. Nodes can join or leave at any time and are 
free to move around as they desire. There is no centralized infrastructure and 
so all participating nodes need to function both as end nodes and routers. Be- 
cause the radio transmission range is limited, packets to distant recipients have 
to be routed over some intermediate node(s) in order to reach nodes outside 
direct transmission range. If one node has a path to another node, packets are 
expected to be routed there correctly. 
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Fig. 1. A mobile ad hoc network 



The situations in which ad hoc networks can or will be applied are still a topic 
of discussion, but scenarios such as search-and-rescue operations and sensor net- 
works have been suggested [11, 16]. An ad hoc network needs a specifically de- 
signed routing protocol. There is ideally no pre-configuration in such a network 
and the network structure is expected to change constantly over time. There- 
fore, the nodes do not know beforehand or even during a session exactly which 
nodes are currently their direct neighbors. Consequently, most ad hoc routing 
protocols are based on broadcasting as a way to detect and map the current 
surroundings. There have been numerous ad hoc routing protocol proposals [28]. 
Currently, four of these are being considered for standardization by the Inter- 
net Engineering Task Force (IETF) MANET group [9]. They are AODV [20], 
DSR [12], OLSR [4] and TBRPF [19]. Very few attempts have so far been made 
to formally verify their operation. 

As in most other computer networking areas, simulations and live testing [16] 
are most often employed to verify new protocols. The “Network Simulator - 
ns2” [10] is commonly used for simulation studies, and for real-world comparisons 
an assisting tool such as the “Ad hoc Protocol Evaluation (APE) testbed” [17] 
can be utilized. Testing and simulation are not sufficient to verify that there are 
no subtle errors or design fiaws left in a protocol. If this goal is to be achieved 
approaches based on formal methods will be needed. Our emphasis is deliberately 
on automatic tools, since they are easier to use for non experts. 

As a case study, the Lightweight Underlay Network Ad hoc Routing protocol 
(LUNAR) [23] has been used. LUNAR has relatively low complexity compared 
to many other ad hoc routing protocols and is intended as a platform to explore 
novel ad hoc routing strategies. Even so, it has been shown to compete well with 
more complex protocols such as OLSR and AODV [23]. The simplicity of the 
core functionality in LUNAR enables us to more clearly study the modeling of 
properties which are not tied to the protocol itself, such as connectivity, dynamics 
and broadcasting. This way we can identify key considerations that apply to the 
modeling of any ad hoc routing protocol. 

The remainder of the paper is organized as follows. Section 2 describes ad hoc 
routing protocols, problems that can occur in their operation, as well as a def- 
inition of what we mean by correct operation. This section also introduces the 
LUNAR protocol. Section 3 describes the verification that has been performed. 
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Pros and cons of the different tools are discussed and lessons learned from ap- 
plying them to LUNAR are presented. Section 4 covers relevant related work 
and finally Section 5 provides conclusions and directions for future research. 

2 Ad Hoc Routing Protocols 

2.1 Correct Operation 

The most fundamental error in routing protocol operation (ad hoc or otherwise) 
is failure to route correctly. In addition to this, there are timing considerations 
to be taken into account, since a protocol of this kind needs to be able to react 
swiftly to topology changes. 

In the following, when we say that a path exists between two nodes, we mean 
that the path is valid for some time longer than what is required to complete the 
route formation process. A route formation process is the process at the end of 
which a particular routing protocol has managed to set up a route from a source 
node to a destination node, possibly traversing one or more intermediate nodes. 
The route can thereafter be used to send packets from source to destination until 
the path becomes invalid as the result of a link breakage. This can occur because 
a node moves out of range or because the protocol itself proactively dismantles 
routes after a given time interval. For simplicity intermittent transmission errors 
at the link/physical layer are treated as link breakages in our model. 

A routing loop in a protocol is a situation in which, somewhere along the path 
from the source to its destination a packet can enter a forwarding circle. This is 
very undesirable since there appears to be a valid path, but in reality it cannot 
be used to forward packets to the intended destination. As a practical example 
consider the description of routing loop formation in the original formulation of 
AODV [21] as described by Obradovic [18] (see Example 1). 

Example 1. Looping behavior in AODV. The situation is depicted in Figure 2 
and a brief explanation of the scenario is the following: 

1. Node A initially has a route to node C through node B. The link between B 
and C then suddenly goes down. 




' - . RREP . " 



Fig. 2. Example AODV looping scenario 
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2. The RERR message (an inherent part of the AODV protocol) from node B 
to node A is lost and hence node A is not notified that the route to C has 
become invalid. 

3. Node B then sends out a route request for node C. Node A, still thinking 
that it has a valid route responds that packets for C can therefore be sent 
to it. 

4. The result is a routing loop in which A will send packets for C to node B. B 
on the other hand will send packets for C to node A. 

These types of errors can be very subtle, and even expert designers may not 
be capable of detecting flaws in new protocol specifications. 

To assist us in determining the correctness of a particular protocol we provide 
the following definition. 

Definition 1. Correct operation of an ad hoc routing protocol 

If there at one point in time exists a path between two nodes, then the protocol 
must be able to find some path between the nodes. When a path has been found, 
and for the time it stays valid, it shall be possible to send packets along the path 
from the source node to the destination node. 

The definition says nothing about the behavior of the protocol when there 
are no paths between the nodes, but note that it excludes the possibility of 
loops when valid paths are available. Consider the scenario above in situation 
4. If the link between nodes B and C goes up again then there is a valid path 
between A and C, but the protocol will keep using the loop between A and B, 
thus breaking the definition of correctness. 

2.2 LUNAR A Protocol Overview 

Lightweight Underlay Network Ad hoc Routing (LUNAR) [23] is a reactive ad 
hoc routing protocol. The term “reactive” is used to denote that the protocol 
discovers paths only when required. However, route maintenance is proactive 
meaning that LUNAR rebuilds active paths from scratch every three seconds. 

LUNAR creates an Internet Protocol (IP) subnet illusion by placing itself 
below the IP layer and above the link layer, i.e. at “layer 2.5” . The IP layer of the 
platform on which LUNAR is running is not aware of the presence of LUNAR. 
Outgoing Address Resolution Protocol (ARP) solicit requests are trapped by 
LUNAR at which point its own multi-hop route request procedure is initiated. 
When a route reply has been received, the ARP table of the host is manipulated 
to contain an IP— >selector mapping instead of an IP— >Medium Access Control 
(MAC) address mapping. Selectors are addressing units analogous to the notion 
of a port and are used by LUNAR to determine the correct operation to perform 
on a given packet. Hence, when an outgoing IP packet is trapped, LUNAR 
uses the selector to determine the path for the packet. The packet is thereafter 
wrapped in a so called SAPP (Simple Active Packet Format) packet and delivered 
to its destination. When a SAPF packet is received by a node, the selector value 
which it contains is used to determine if it has reached its final destination, in 
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Fig. 3. LUNAR route formation overview 



which case it is delivered up the IP stack. If this is not its final destination, it is 
forwarded along the next hop. 

Broadcast dampening is an important part of the protocol and makes sure 
that packets are not rebroadcast more than once, thus avoiding broadcast storms. 
Typical usage areas for LUNAR are spontaneous ad hoc networks and wireless 
ad hoc Internet access links. Example 2 gives a short informal explanation of 
the route formation process in order to facilitate the understanding of the algo- 
rithm. Note that the simultaneous back path creation has here been omitted as 
a modeling simplification. 

Example 2. LUNAR route formation. The situation is depicted in Figure 3. In 
the figure grey, dashed, bidirectional arrows indicate connectivity. The black, 
solid, unidirectional arrows indicate paths that have been set up in the network. 
An overview of the route formation process is as follows. 

1. Node A wants to set up a route to node C and therefore broadcasts a LUNAR 
route request (RREQ). 

2. The RREQ is only received by node B who concludes that it is not the node 
sought and therefore rebroadcasts the request. Before doing so, however, it 
connects the new request to a back path back to the originally requesting 
node (which is A). 

3. The RREQ is now received by both A and C. A, through the use of the 
dampening mechanism concludes that the request originates from itself and 
drops it. C on the other hand, receives and handles the request. Since it 
is itself the requested node it sets up a “port” for later reception of IP 
packets, after which it generates a route reply (RREP) destined for B. When 
B receives this RREP it notes that it is a response to an original request 
from A, therefore it forwards the response to A. Before doing so, however, 
it sets up a relay so that packages received for C are forwarded to the port 
set up there. 

4. When A receives the RREP it constructs an outgoing port to which IP 
packets destined for C are to be sent. This port is connected to the relay at 
B which is in turn connected to the port at C. 
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3 Case Study: Verification of LUNAR 

3.1 The Model and Its Limitations 

We have used a somewhat simplified version of LUNAR for our verification [27]. 
Apart from the simultaneous back path creation, features [23] such as automatic 
address configuration and forced route rediscovery, etc. are missing in our de- 
scription. The same goes for the RREQ Time To Live (TTL) field since the 
diameters of the networks studied are small enough that we do not need to limit 
them explicitly. 

3.2 Central Modeling Issues 

When modeling an ad hoc network protocol, apart from the usual considerations 
regarding limiting the resulting state space, the following questions are central: 

— How do we model broadcast? 

— How do we model connectivity? This influences the handling of broadcast. 

— How do we model topology changes (dynamics)? This directly influences the 
connectivity graph. 

In the two sections that follow, besides giving our model checking results, we 
describe our solutions to each of the above issues. 



3.3 Verification Using SPIN 

SPIN [7] is a model checking tool that can be used for formal verification of 
distributed software systems. System descriptions are given in the high level 
language PROMELA (PROcess MEta LAnguage) and requirements to be veri- 
fied can either be given as assertions directly in the code and/or by specifying 
correctness properties as Linear Temporal Logic (LTL) formulae. SPIN works 
on-the-fiy, i.e. does not need to construct the complete state space prior to ver- 
ification, instead this is done dynamically during processing. Furthermore, as 
a measure to cope with the state space explosion problem, SPIN includes a par- 
tial order reduction algorithm [8]. The state space explosion problem refers to 
the situation in which the state space generated by the model because of paral- 
lelism becomes so large that all the visited states cannot be stored. In the worst 
case the state space grows exponentially with the length of the program. 

We use SPIN because of its relatively low learning threshold and powerful 
model checking capabilities. A PROMELA model of LUNAR has thus been con- 
structed. The model consists of about 250 lines of code excluding comments. Our 
initial approach, and the one described in this work, has been to naively model 
the complete system and model check it as a whole. We feel that demonstrating 
that this is possible will lower the resistance to using these tools and increase 
the chances of more people verifying their protocols. 
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Connectivity and Dynamics. The communication “ports” where each node 
can be reached are modeled using PROMELA channels stored in an array in- 
dexed by node id. Node id and MAC address are used interchangeably in our 
model, which provides a straightforward addressing of nodes. To model connec- 
tivity a symmetric, two dimensional, array of boolean values is used. The matrix 
is symmetric since we assume nodes to be connected bidirectionally. 

Node dynamics are modeled by modifying the connectivity matrix. In order 
to reduce complexity, nodes either have or do not have connectivity. No inter- 
mediate state is possible as it would be in a more realistic link/physical layer 
model. It would be straightforward to model lower layers in a more detailed way, 
but this again increases complexity and reduces the chances of successful model 
checking because of the state space explosion problem. 

Broadcasting. Due to the transient nature of radio communication, broadcast 
is heavily used in most ad hoc networking protocols and LUNAR is no excep- 
tion. In our model, broadcast is modeled by unicasting to all nodes with whom 
the sending node presently has connectivity. A PROMELA macro has been con- 
structed for this operation. This macro consults the corresponding row in the 
connectivity array for the sending node and sends to all connected nodes using 
the channel array. The unicast operations that represent a broadcast are imple- 
mented atomically to ensure that no connectivity interruptions occur part way 
through the process. 



Limitations Imposed. In LUNAR, both remote and local selectors are ran- 
domly selected from different ranges. Since they are specified to be 64 bits 
long [23], the space of possible values is huge. In our PROMELA model we 
are therefore forced to pick the selectors from a few limited values. 

The local selectors, as their name implies, do not have to be globally unique 
and are therefore selected from the same range for all nodes. However, the remote 
selectors are meant to be globally unique and are chosen from different ranges. 
When a new selector is needed, the selector port value is just monotonically 
increased and assertions are used to make sure that the bounds are not violated. 
The correct bounds to use are selected by experimentation. The abstraction of 
selector values to a fairly limited range thus has no impact on the verification 
since this range is set to accommodate the needed amount of values. 

The abstraction of remote selector values could have had an influence on 
the verification result if there was a possibility that the random selector values 
in an implementation of the protocol were likely to coincide. However, because 
of the large value space, this possibility is so minor that we consider it to be 
insignificant. 

Channel sizes, i.e. the number of outstanding messages in a channel at one 
time, are in general kept as small as possible. These are selected by experimen- 
tation to hold the required number of outstanding messages and do therefore 
not have any impact on the verification results. 
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Verification. The verification of the protocol is performed by setting up the 
model so that one node tries to send an IP packet to another node in the network. 
The topology and node transitions are selected so that the two nodes are always 
connected, possibly by traversing one or several other nodes. Initially, no routes 
are set up in the network. The sending node therefore needs to initiate a route 
discovery process and does so by sending out a LUNAR RREQ broadcast. If 
and when it receives a reply it thereafter tries to send the IP packet along the 
route that was set up. New RREQ:s are forced after topology changes and on 
timeouts. 

A global boolean message_delivered is set to true when the correct re- 
ceiving node has received the correct IP packet from the sending node (tagged 
accordingly). A hop counter keeps track of the nodes traversed by the packet 
before it reaches its destination and an assertion is used to verify that it does 
not traverse more nodes than theoretically possible in the absence of loops. This 
assertion is checked at the receiving node prior to setting message_delivered. 

Finally, another assertion is used in a timeout statement in order to check 
that when one node times out because of inactivity, then message_delivered 
is true and the message has indeed been delivered. Using SPIN we also check 
for the absence of deadlocks and conformance to the LTL formula <>message_ 
delivered which verifies that a message will eventually be delivered. 

In total, this is sufficient to show that the protocol functions correctly in 
each situation studied according to the statement in Definition 1. In all our sce- 
narios we have explicitly made certain that there is a possible path between the 
two communicating end nodes and that each transition maintains this property. 
If LUNAR had any looping behavior detectable in these situations, the LTL 
formula above would not be fulfilled. 

In our initial approach, the number of nodes is specified and then a topology 
is generated nondeterministically. A recursive graph traversal is then performed 
to see if there is a communication path possible between nodes 0 and 1. If there 
is not, the program ends. If there is a possible path, then the node processes 
are initiated and the route discovery is started, etc. In this manner, all possible 
topologies are considered. 

However, using this approach, the state space is already large without any 
node connectivity transitions. When node mobility is also added, it is no longer 
feasible to perform an exhaustive search even for a small number of nodes. There- 
fore, we choose to focus on a few especially interesting scenarios which are de- 
picted in Figure 4. These scenarios have been selected in an attempt to capture 
situations that could cause problems for the protocol. In scenarios (a), (c), (d), 
(e), (g) and (h) a situation can occur in which a route has been set up, but 
is then broken before the packet could be delivered. In this case, a new route 
should successfully be set up and the packet delivered along that one instead. In 
(b), (d) and (f) an extra node suddenly appears, which could potentially cause 
confusion for a routing protocol. 

For scenarios (a), (b), (c), and (e) we are able to verify correct operation. 
This effectively shows that LUNAR is loop free for these topologies (and node 



Automatized Verification of Ad Hoc Routing Protocols 



351 



(a) 






© 




(b) 


© 




(O 


(d) 

,.© ,.® 




© 






(S'. 


i ’> 








(S 








^®;| ® |:©^ 




,® - 








'-(S' 




















■®''' 






(e) 










(f) 






(g) 


(H) 
















© 






© 






,.© ® ,,©- 






■©. 


® 


(s; 










(S; 




lx 


1® - ® \ ,,® ® i t 


)| 


1® - ®;' 








''(S' 












''(S' 


'©' ©’ 


'■© & '© 






"® 


■® 












Fig. 4. 


Example 


classes of topology changes 











transitions). For scenarios (d) and (f) we are not able to perform an exhaustive 
search because of the state space explosion (see further below). Scenarios (g) 
and (h) are not checked using SPIN. 

Since we are doing brute force model checking it becomes important to uti- 
lize the most powerful hardware available. For this reason, we have used a Sun 
Fire 15k server with 36 UltraSPARC III-I- CPUs at 900 MHz and 36 Gb of pri- 
mary RAM to model check our scenarios. Unfortunately, SPIN models cannot 
currently be compiled to take full advantage of a multi-threaded architecture. 
There has been work on distributed LTL model checking algorithms for SPIN 
by Brim et al [1] and they have also implemented an experimental version. The 
performance increase is reported as promising. However, at this time there is no 
SPIN implementation with this feature publicly available. 

Table 1 shows our results for scenarios (a)-(f). SPIN is here used in exhaustive 
search mode as opposed to the approximating bitstate hashing and hash-compact 
modes since we are interested in verifying correctness. Further note that both 
partial order reduction and COLLAPSE compression [7] are used everywhere. 
As a reference, the values with only partial order reduction are given within 
parentheses (where they differ). As can be seen, the state space rapidly grows 
with the number of nodes. Even using four nodes, when topology changes become 
just a bit more complex, the model checking fails because of memory restrictions 
(32 bit application). Interesting to note is that for both four and five nodes, the 
state space becomes much larger for the situation where one intermediate node 
comes up after a while, than when it goes down. 



3.4 Using UPPAAL to Prove Timing Requirements 

UPPAAL [15] is a tool that can be used to verify real time aspects of computer 
systems. The UPPAAL home page [25] provides the following definition: “UP- 
PAAL is an integrated tool environment for modeling, validation and verifieation 
of real-time systems modeled as networks of timed automata, extended with data 
types (bounded integers, arrays, etc.)”. The environment has a graphical user 
interface in which the automata are constructed by drawing them in a window 
on the screen. The tool contains a simulator and a verifier in which requirements 
are given as LTL formulae. 

An UPPAAL model has been constructed in order to check timing require- 
ments of LUNAR. The timing aspects that we focus on are to determine the- 
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oretical lower and upper bounds on the route formation and message delivery 
processes. We also check that the LUNAR model is deadlock free. In our UP- 
PAAL model we introduce more abstraction than in the SPIN model. The main 
reason for this is the unavailability of more complex data structures than arrays 
which becomes relevant in the handling of LUNAR callbacks and redirections. 



Timing Constraints. As mentioned before, the setting up of routes in an ad 
hoc network is usually slower than in a conventional more static network. This 
is because the topology needs to be rediscovered (usually by broadcasting) at 
regular intervals. There is a tradeoff between the exchange of control packets 
(used for topology analysis) and the delivery of data packets in the network. We 
want to achieve an optimal balance that keeps the data packet delivery times as 
low as possible. 



Connectivity and Dynamics. As in the SPIN model, the UPPAAL model 
uses arrays of booleans to represent inter-node connectivity. Either, there is 
connectivity between two nodes or there is not. Node connectivity transitions 
are modeled using a separate automaton, that can at any time move to its next 
state whereby it manipulates the (global) connectivity table. 



Broadcasting. In our version of UPPAAL broadcast channels can be used 
for synchronization. However, communication can not be used for value passing 
in UPPAAL and instead a combination of global data holders and committed 
locations is the recommended procedure [25]. In our LUNAR UPPAAL model 
broadcasting is handled similarly to unicasting except that the sending node (i.e. 
the broadcast initiator) has to specify that a broadcast is intended. Then, the 
medium automaton will set a global parameter bc_sender specifying the sender’s 
identity. This is, because in the case of broadcast, the connectivity check has been 
deferred to the receiving nodes. 



Table 1. SPIN verification results 



Scenario States Transitions All states Memory Time 
generated searched used [Mb] used 



(a) 


5715 


12105 


Yes 


(b) 


269886 


731118 


Yes 


(c) 


53614 


128831 


Yes 


(d) 


4.58e+07 


1.33e+08 


No 




(8.15e-t06) (2.21e+07) 




(e) 


1.41e+06 


4.59e+06 


Yes 


(f) 


3.40e+07 


1.22e+08 


No 



(7.27e+06) (2.50e+07) 



4.242 (6.188) 0.20 (0.20) s 
33.05 (124.7) 12.33 (10.48) s 
8.836 (30.12) 2.19 (1.92) s 
4083 (4083) 5 h:57 min 
(8 min:56 s) 

170.4 (806.6) 1:36 (1:26) min:s 
4083 (4083) 4 h:2 min 
(9 miu:43 s) 
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Limitations Imposed. The limitations in the PROMELA model are also im- 
posed on the UPPAAL model, for the same reasons. An additional limitation 
that becomes relevant in the UPPAAL model is that it does not take into account 
computation times in the nodes. The only places in which delays occur are in the 
communications. This has been modeled by using a range, [MIN_TRANSMIT_TIME, 
MAX_TRANSMIT_TIME] of possible delays. It provides a very rough approximation 
of wireless network conditions and can in future versions be exchanged for a more 
realistic Wireless Local Area Network (WLAN) model. There are such models 
available [13], but we here choose the simplistic approach for lower network layers 
in order to reduce complexity. 

In current LUNAR implementations the RREQ resending is done in an elab- 
orate way attempting first a limited discovery using a small network radius. After 
this, several attempts are made with a larger radius. A timeout value is specified 
per “ring”, i.e. per number of hops from the source node. After each RREQ 
timeout there is an additional waiting period before making a new attempt. In 
our model, however, we have chosen to settle for two timeout triggered resends. 
This means that in total, three route formation attempts can be made. In com- 
bination with a properly chosen timeout value, this is theoretically enough to 
successfully set up a route (and deliver a packet) in the scenarios studied. Our 
selected timeout value of 75 ms corresponds to three times the “ring” timeout 
in current LUNAR implementations. 



Verification. The verification is performed in a manner analogous to the one 
described in Section 3.3. Namely, one node tries to set up a route to another 
node after which it attempts to send a packet there. If the route could be set up, 
the initiating node goes into a state unicjrrepjrec. If and when the correct IP 
packet arrives at the receiver, it goes into a state ipjrec_ok. Using our UPPAAL 
model we then verify deadlock freedom as well as timely route formation and 
message delivery. The LTL formulae in Table 2 are used to verify the respective 
properties. 

There has been work done on extending UPPAAL to perform parallel model 
checking by Behrmann et al [2] . The advantage gained is increased speed which 
would in our case e.g. enable checking a wider range of scenarios. However, the 
total required amount of memory is larger since the state space grows when 
exploration is parallelized [2]. We have chosen to just study the standard (non 
parallel) UPPAAL distribution here. 



Table 2. LTL formulae used with UPPAAL model 



Property LTL formula 

Deadlock freedom A[] not deadlock 

Route successfully set up A<> Lunar0.unic_rrep_rec 

IP packet delivered A<> Lunarl . ip_rec_ok 
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Table 3. UPPAAL verification results 



Scenario Route Message 

formation delivery 
time [ms] time [ms] 


States 

searched 


Search 

complet- 

ed 


Memory 

used 

[Mb] 


Time 

used 


(a) 


[8, 91] 


[12, 99] 


15072 (12789) 


Yes 


15.98 (16.10) 


3.89 (3.23) s 


(b) 


[8, 16] 


[12, 24] 


12211 (9787) 


Yes 


11.42 (11.48) 


2.85 (2.56) s 


(c) 


[8, 91] 


[12, 99] 


22783 (18613) 


Yes 


20.12 (17.28) 


5.93 (5.01) s 


(d) 


[8, 91] 


[12, 99] 


50456 (41169) 


Yes 


37.37 (35.51) 


14.91 (12.26) s 


(e) 


[8, 91] 


[12, 99] 


123196 (106257) 


Yes 


124.0 (109.0) 


57.91 (50.44) s 


(f) 


[8, 16] 


[12, 24] 


134978 (109606) 


Yes 


77.39 (77.24) 


47.58 (42.61) s 


(g) 


[12, 99] 


[18, 111] 


2.01e-t06 


Yes 


866.6 


11:43 min:s 








(1.78e+06) 




(779.4) 


(10:28) 


(h) 


- 


- 


2.97e-t07 


No 


4078 


1:59 h:min 








(2.63e+07) 




(4082) 


(1:50) 



With the scenarios and hardware described in Section 3.3, the route forma- 
tion and message delivery times in Table 3 result. UPPAAL is here used with 
aggressive state space reduction [2, 14]. As a reference, the values for conserva- 
tive state space reduction (the default) are given within parentheses. In all our 
measurements the state space representation uses minimal constraint systems. 

The memory and time usage in Table 3 pertains to the case where all three 
LTL formulae in Table 2 are checked. As communication delay we have used 
the range [2, 4] ms. These measurements cannot be directly compared to the 
ones in Table 1 for the SPIN verification because of the greater amount of ab- 
straction introduced in the UPPAAL model. The RREQ generation strategy 
also differs between the models because of the absence of timing in the SPIN 
model. However, similar observations can be made for UPPAAL to those made 
in SPIN, namely that the state space grows rapidly with the number of nodes. 
Also, the nature of the topology changes influences the state space in a way 
that may sometimes be difficulty to foresee. Further note in the timing values 
that the shortest possible path is always the one found because of the rough 
link/physical layer approximation with total determinism in packet delivery. 

4 Related Work 

The Verinet group [26] at the University of Pennsylvania have carried out formal 
validation of AODV [18] and identified a flaw that could lead to loop formation. 
This was done using the HOL [24] theorem prover and a SPIN model of AODV in 
a two node setup (with an AODV router environment) . They have also suggested 
a modification and verified that, after this, the protocol was loop free. Their 
approach verified the general case, but the methodology involves substantial 
user interaction. 

Das and Dill [5] have used predicate abstraction to prove the absence of 
routing loops in a simplified version of AODV. The method yields a general 



Automatized Verification of Ad Hoc Routing Protocols 



355 



proof but requires human involvement in the construction of the abstraction 
predicates. 

Engler et al [6] have studied three implementations of AODV and found 36 
distinct errors, including a bug (routing loop) in the AODV specification itself. 
The authors used their own model checker called CMC, which checks C and C++ 
implementations directly, eliminating the need for a separate abstract description 
of the system behavior. The model checker performs its work automatically. 
However, prior to execution, in addition to specifying correctness properties, the 
user has to define an environment as well as providing guard functions for each 
event handler. Furthermore, their approach is not aimed at proving correctness, 
but rather as a method of finding bugs in the code since an exhaustive state 
space search can generally not be performed. 

Chiyangwa and Kwiatkowska [3] have constructed an UPPAAL model of 
AODV in order to investigate timing properties of the protocol. To cope with the 
state explosion problem, a linear topology has been used with sender, receiver, 
and an intermediate njnodes node. Using 12 intermediate nodes, the authors 
could conclude that the dependency of route life time on network size is undesir- 
able and suggested a modification where it instead adapts as the network grows. 
This work is closely related to ours, but they have focused on UPPAAL and 
studied a single (linear) scenario type. The methodology involves manual con- 
sideration in constructing the specialized model. Apart from studying a different 
protocol, we have taken a broader view comparing two verification approaches 
with an emphasis on the modeling of connectivity, dynamics and broadcasting. 

Xiong et al [29] have modeled AODV using colored Petri nets (CPN). To 
cope with the mobility problem they have proposed a topology approximation 
(TA) mechanism. Simulation results show that the TA mechanism can indeed 
simulate the mobility of a MANET without knowing its actual topology. 

Theo Ruys’ PhD thesis [22] discusses different methods for modeling broad- 
cast in SPIN. An alternative to our connectivity array would be to use a matrix 
of channels. Furthermore, instead of a broadcast macro, a broadcast service pro- 
cess could have been used. Since we have utilized asynchronous channels with 
large enough capacity for the broadcasts, this choice has not had any impact on 
the asynchronous nature of the message delivery process. 

5 Conclusions and Future Work 

This work is to our knowledge the first to study a range of topologies in order to 
determine where the limit actually is when performing model checking on an ad 
hoc routing protocol. We demonstrate that LUNAR works correctly (according 
to our general definition) for a number of routing scenarios. We further provide 
bounds for route formation and message delivery times. 

When verifying both the data and control aspects of the LUNAR protocol 
using SPIN and when verifying the timing properties using UPPAAL the size of 
network, i.e. the number of nodes involved, as well as the nature of the topological 
scenarios is limited due to state space storage overhead. Even if parallel model 
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checking approaches were used, our conclusion is that it is at this point not 
feasible to provide a proof for topologies of any significant size by modeling the 
protocol directly. On the other hand, our study enables us not only to analyze 
the modeling considerations that have to be imposed, but also provides us with 
a solid starting point for the further work we intend to pursue in the direction 
of infinite-state verification of ad hoc routing protocols. 

Our emphasis has been on automatic model checkers in which the user pro- 
vides a system specification and a number of requirements to check. The con- 
struction of models for these tools naturally still involves a certain amount of 
manual consideration. However, now that many of the modeling considerations 
have been identified, constructing verifiable models for both tools can be made 
rather close to the engineering activity of programming. Ultimately our goal is 
for the whole process to require knowledge primarily of the application, namely 
the ad hoc routing protocol, and not of the model checking tool. At present it 
is still necessary to manually (experimentally) limit the topologies and devise 
LTL formulae. This can be remedied by introducing specialized macros in com- 
bination with an ad hoc routing protocol preprocessor. Standard formulae could 
thereby be used for common situations, e.g. route setup and packet delivered. 

We aim to evaluate current and upcoming parallel model checking tools in 
order to see where the limit in terms of number of nodes and topology dynamics 
currently is. We will perform these analyses on a super computer which has a very 
large amount of primary memory available. Further studies are also planned 
which involve other ad hoc routing protocols such as the ones being considered 
for standardization by the MANET group. 

In order to provide a general proof of correctness in an automatic way, it is 
however not enough to study just a limited set of topologies. We need to study 
all available permutations for any given number of nodes. Therefore we will focus 
on the following directions for future research: 

— Isolate the critical aspects of the ad hoc routing protocol to hand and model 
check those. A theorem prover can then be used to construct a general proof. 
This requires significant user interaction. It would be a great advantage if 
this process can be made more automatic. 

— Employ a formal construction method rather than a post-construction verifi- 
cation and evaluate if there are ways to make that process more user friendly. 

— Attempt an automatized infinite-state verification approach. 

We currently consider the last approach as the most promising in terms of 
simplifying the verification process while still being able to provide a general 
proof. 
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Abstract. We propose a framework for intrusion detection that is based 
on runtime monitoring of temporal logic specifications. We specify intru- 
sion patterns as formulas in an expressively rich and efficiently mon- 
itorable logic called Eagle. Eagle supports data-values and parame- 
terized recursive equations, and allows us to succinctly express security 
attacks with complex temporal event patterns, as well as attacks whose 
signatures are inherently statistical in nature. We use an online moni- 
toring algorithm that matches specifications of the absence of an attack, 
with system execution traces, and raises an alarm whenever the speci- 
fication is violated. We present our implementation of this approach in 
a prototype tool, called Monid and report our results obtained by ap- 
plying it to detect a variety of security attacks in log-files provided by 
DARPA. 

Keywords: Intrusion detection, security, temporal logic, runtime mon- 
itoring 



1 Introduction 

Despite great progress in research on computer security, fully secure computer 
systems are still a distant dream. Today any large and complex computer system 
has many security flaws. Intrusion detection involves monitoring the system 
under concern to identify the misuse of these flaws as early as possible in order 
to take corrective measures. 

There are two main approaches to intrusion detection: signature-based [10, 12] 
and anomaly-based [1, 6, 14]. In the signature-based approach, system behavior 
is observed for known patterns of attacks, while in the anomaly-based approach 
an alarm is raised if an observed behavior deviates significantly from pre-learned 
normal behavior. Both these approaches have relative advantages and disadvan- 
tages. The signature-based approach has a low false-alarm rate, but it requires us 
to know the patterns of security attacks in advance and previously unknown at- 
tacks would go undetected. In contrast, the anomaly-based approach can detect 
new attacks, but has a high false-alarm rate. 

In this paper, we adopt a temporal logic approach to signature-based intru- 
sion detection. One can naturally specify the absence of a known attack pattern 
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as a safety formula (f in a, suitable temporal logic [5]. Such a temporal logic 
based approach was considered in [16] using a variant of linear temporal logic 
(LTL) with first order variables. However we consider a more expressive logic 
in which one can also express attack signatures involving real-time constraints 
and statistical properties. We show how to automatically monitor the specifica- 
tion (/) against the system execution and raise an intrusion alarm whenever the 
specification is violated. We also show how this technique can be used for simple 
types of anomaly-based intrusion detection. The idea is to specify the intended 
behavior of security-critical programs as temporal formulas involving statistical 
predicates, and monitor the system execution to check if it violates the formula. 
If the observed execution violates the formula then an intrusion has occurred, 
and thus attacks can be detected even if they are previously unknown. 

Our approach to intrusion detection is motivated by the success of the rel- 
atively new research area called runtime verification [8, 18, 20], a major goal 
of which is to use light-weight formal methods for system monitoring. We use 
Eagle, introduced in [4], for specification of attack-safe behavior of a system. 
Eagle supports recursively defined temporal formulas, parameterizable by both 
logical formulas and data-expressions, over a set of three primitive modalities 
“next” , “previous” , and “concatenation” . The logic enables us to express tempo- 
ral patterns that involve reasoning about the data- values observed in individual 
events, and thus allows us to specify attacks whose signatures are inherently 
statistical in nature. Examples include password guessing attacks or the ICMP- 
flood denial of service attack. For these attacks there is no clear distinction 
between an intrusion and a normal behavior, and their detection involves col- 
lecting temporal statistics at runtime and making a guess based on the collected 
statistics. 

We use an online algorithm [4] to monitor Eagle formulas that processes 
each event as soon as it occurs and modifies the monitored formula to store the 
relevant summary. If, after any event the modified formula becomes false, an 
intrusion alarm is raised. Thus the whole procedure works in real-time. We have 
implemented our proposed approach in a prototype tool called Monid which 
can detect intrusions either online or offline. Figure 1 illustrates the framework. 
Information about system-level events, obtained either from relevant log-files (of- 
fline) or generated by appropriately instrumented application code (online), are 
sent to a server. The server merges the events from various sources by timestamp 
and preprocesses them into an abstract intermediate form to generate a single 
event trace. Note that detecting certain attacks may require us to observe events 
from various sources. Our monitor subsequently monitors this event trace against 
a given specification, and raises an intrusion alarm if the specification is violated. 

We show the effectiveness of our approach by specifying several types of 
attacks and by monitoring them using Monid. Specifically, we perform offline 
monitoring using the large log-files made available by DARPA exclusively for 
the task of evaluating intrusion detection systems [13]. We successfully detected 
the attacks specified with acceptable computational overheads for the monitor- 
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ing procedure. The experiments suggest that the proposed approach is a viable 
complement to existing intrusion detection mechanisms. 

Following is the layout of the rest of this paper: In Section 2 we discuss related 
work in the area of intrusion detection and motivate our work. In Section 3, we 
briefly describe the syntax, semantics, and monitoring algorithm for Eagle fol- 
lowed by Section 4 where we illustrate several common security-attack patterns 
specified in Eagle. In Section 5, we describe the implementation of our tool 
Monid followed by a summary of our experimental results on DARPA log-files. 
We conclude in Section 6 with a brief discussion about future research directions. 

2 Background and Motivation 

The area of intrusion detection has seen synthesis of concepts and techniques 
from a variety of disciplines, including expert systems [1, 17], artificial neural 
networks [6], data mining [14], and static analysis [22]. A diverse collection of 
tools based on these various approaches have been deployed and tested [2, 7]. 
In the following, we elaborate on some of these approaches and clarify how our 
work fits in this context. 

For signature-based approaches there are several languages with varying de- 
grees of expressivity for specifying attack patterns. Roger et al. in [16] used tem- 
poral logic and model-checking based approach to detect intrusion. This work 
is closely related to ours; however, unlike [16] we can express more sophisti- 
cated signatures involving statistics and real-time by using powerful monitoring 
logic Eagle. Ilgun et al [10] propose the use of finite state transition diagrams 
to specify sequences of actions that would lead the system from a secure ini- 
tial state to a compromised final state. Ko et al [11] introduce a new class of 
grammars, called parallel environment grammars that are specifically suitable 
for specifying behavior (traces) of concurrent processes. The expected behavior 
of security critical programs is specified by a grammar, and an alarm is raised 
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if the observed execution trace is not in the language defined by the grammar. 
Kumar et al [12] propose the use of Colored Petri nets for specifying attack 
patterns. We note that in comparison to the other approaches, temporal logic 
specifications of attack signatures tend to be much more compact and simpler 
to describe. 

The state transition diagram and colored Petri net approaches can be seen 
as special cases of rule-based expert systems [9]. In rule-based expert systems, 
in general, knowledge about attacks is represented as a collection of if-then 
rules which are fired in response to the observed system execution. The main 
advantage of this approach is the clear separation of knowledge base from the 
control mechanism that applies the knowledge base for detecting intrusions. 

In contrast to the signature-based approaches such as the above, the anomaly- 
based approach to intrusion detection does not require a priori knowledge of the 
attacks. One such approach is to collect statistical information [1, 15] about 
normal behavior into a user, group or target machine profile, and raise an alarm 
if the observed behavior deviates significantly from an estimated profile. One of 
the most rudimentary ones is threshold detection, where the idea is to record the 
number of occurrences of specific events and raise an alarm if the number is not 
within an expected range. As we will see in Section 3, such threshold detection 
policies can be elegantly expressed as temporal logic formulas. 

Statistical profile-based anomaly detection can be seen as an instance of the 
general class of intrusion detection systems that learn the normal system be- 
havior by constructing some model for it, and use the model to predict the 
system behavior and detect suspicious deviations. Other approaches in this cat- 
egory include that of time-based inductive generalization [21], artificial neural 
networks [6], and data-mining[14]. In time-based inductive generalization, the 
system behavior is modeled as a set of rules that are dynamically modified dur- 
ing the learning phase depending on how the predictions of the rules match with 
the observed system behavior. In the artificial neural networks approach, a neu- 
ral net constitutes the model of system behavior and the net is trained with 
representative normal scenarios. In the data-mining approach, large audit trails 
are mined for patterns of normal or abusive behavior, which are then used for 
signature-based or anomaly-based intrusion detection. Self-learning capabilities 
such as the above are beyond the scope of our approach which is only intended 
for detecting attacks whose patterns are known a priori. 

Anomaly-based intrusion detection systems have the disadvantage of hav- 
ing high false alarm rates due to inaccuracies in the learned model. In contrast, 
signature-based approaches such as ours have low false alarm rate, but would fail 
to detect attacks that differ even slightly from the given signature. Ideally, one 
would like a self- learning intrusion detection system with low false alarm rates. 
For now, the signature-based systems are quite popular because of their simplic- 
ity, accuracy, and ease of use. These systems would in any case be a valuable 
supplement to build more accurate anomaly-based systems. 
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3 Eagle: An Expressive Temporal Monitoring Logic 

The patterns for security attacks in software systems are specified formally in 
the logic Eagle which is designed to support finite trace monitoring, and con- 
tains a small set of operators. The logic Eagle introduced in [4] supports re- 
cursive parameterized equations, with a minimal/maximal fix-point semantics, 
together with three temporal operators: next-time (0)i previous-time (O), and 
concatenation (•). Rules which are used to define new temporal operators can 
be parameterized with formulas and data-values, thus supporting specifications 
that can involve data, which can span an execution trace. The expressivity of 
Eagle, which is indeed very rich, as shown in [3, 4], can express properties in- 
volving real-time, statistics and data-values. To make the paper self-contained, 
in this section, we give an informal introduction to Eagle followed by its syntax, 
semantics, and the runtime monitoring algorithm for Eagle as described in [4]. 
The logic Eagle and its monitoring algorithm assumes the following: 

1 . There is a finite sequence of events cr generated by some executing system. An 
event is an instance of a record having a pre-specified schema. For example, 

LoginLogoutEvent {wser/d : string, action', int, time, double ) 

is the schema of an event and {userid = "Bob", action = login, time = 
18.7} is an event representing the fact that user "Bob" has logged in at time 
18.7. 

2. There is a formula F in Eagle which specifies the condition for the absence 
of an attack. 

We say that cr is free of the attack specified by F if and only if a satisfies F. 

Now, assume that we want to state a property that ’’Whenever there is 
a login then eventually there is a logout”. The property can be written in classical 
future time LTL: D{action = login — > (){action = logout)). The formulas DE 
(always F) and ()F (eventually E), for some property E, satisfy the following 
equivalences, where the temporal operator Q)F stands for next F (meaning ‘‘in 
next state E’): 

□e = eaO(de) oe = evO(OE) 

One can show that DE is a maximal solution of the recursive equivalence X = 
F A O^j while (}F is the minimal solution of X = E V O^- In Eagle one can 
write the following definitions for the two combinators Always and Eventually, 
and the formula to be monitored (Mi): 

max Always ( Form E) = E A Qkl'wa.'ys{F) 

min Eventually ( Form F) — F V OEyentually(E) 

mon Ml = Always ((action = login) — > Eventually (action = logout)) 

The Always operator is defined as having a maximal fix-point interpretation; the 
Eventually operator is defined as having a minimal interpretation. For further 
details the readers are referred to [4]. 

Let us complicate the above property a bit by stating that “Whenever there 
is a login by any user x then eventually the user x logs out.” Thus, if "Bob" logs 
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in then eventually "Bob" must logout. Similarly, the property must hold for any 
user such as "Tom", "Jim" or "Kelly". This property can be expressed by the 
following LTL formula with data-value bindings: 

ni{{action = login) ^ 1^ k = userid in () {action = logout A userid = k)) 

In this formula we use the operator let _ in _ to bind the value of userid in the 
current event to the local variable k whenever action = login in the current 
event. We then impose the condition that the value of userid in some event in 
future must be same as the user id bound to k and that the action of the event 
must be logout. In Eagle, we use a parameterized rule to express this property, 
capturing the value of userid as a rule parameter: 

min Bind(string k) = Eventually (action = logout A userid = k) 
mon M 2 ~ Always ((action = login) ^ Bind(Mser/d)) 

Rule Bind is parameterized with a string k, and is instantiated in M 2 when 
action = login, hence capturing the value of userid at that moment. Rule Bind 
replaces the binding operator 1^ _ in _. 

Indeed one can combine the two rules Bind and Eventually into a single 
rule EvLogout with one parameter to get the same monitor as follows: 

min EvLogout (string k) = {action = logout A userid = fe) V OEvLogout(fc) 
mon M 2 = Always ((action = login) — + EvLogout (nser/d)) 

Thus by allowing parameterized rules one gets the power of data-value binding 
in a formula. It can be argued that the introduction of the operator let _ in _ is 
sufficient to get the power of binding. However, parameterized rules can do more 
than simple data-binding. For example, suppose we want to express the property 
that “Whenever there is a login by any user x then eventually the user x logs 
out within 100 units of time.” For this property we modify the rule EvLogout 
by introducing two more parameters denoting the time at which the previous 
event took place and the time left. The modified rule and the monitor is given 
below: 

min EvTimedLogout (string k. double t. double 5) = {S — {time — t) > 0) 

/\{{action = logout A userid = fc) V OEvTimedLogout(fc, time, 5 — {time — t))) 
mon Ms = Always ((action = login) — » EvTimedLogout (ttser/d, time, 100)) 

Note that another simpler alternative to define the rule EvTimedLogout is as 
follows: 

min EvTimedLogout (string fc. double t. double <5) = {time — t < S) 

A{{action — logout A userid = fc) V OEvTimedLogout(fc, t, 5)) 

A possible variation of our requirement for login and logout can be stated as 
’’Whenever there is a logout by any user x then in the past user x must have 
logged in”. This property cannot be expressed concisely using the future time 
temporal operators only. However, the property can be expressed elegantly by 
a mixture of past-time and future-time temporal operators as follows: 

□ ((oction = logout) — > let fc = userid in 0 {action = login A userid = fc)) 
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where (^F denotes eventually in past F. This operator can be defined recursively 
in Eagle using the primitive operator Q which is the past-time equivalent of 
O- Thus the monitor definition can be written as follows: 

min Eventually InPast (Fomi F) = F \/ Q Eventually InPast(E) 
min Bind(string k) — EventuallyInPast( action = logout A userid = k) 
mon M4 = Always ((action = login) ^ Bind(Mser/d)) 

Thus rules in Eagle allow us to define customized temporal operators with 
also the ability to bind and manipulate data. This capability proves to be indis- 
pensable for succinctly expressing attack-safe system executions. We recall the 
syntax and semantics of Eagle to make the paper self-contained. 

3.1 Syntax and Semantics 

Syntax. A specification S consists of a declaration part D and an observer 
part O. D consists of zero or more rule definitions R, and O consists of zero or 
more monitor definitions M , which specify what is to be monitored. Rules and 
monitors are named (N). 

S -.-DO D-.--R* Ov-M* 

R ( max I min ) N(T-\ xi T„, x„.) = F 

M mon N = F 
T Form | primitive type 

F ::= expression \ true | false | ^F \ Fi A F2 \ Fi \/ F2 \ Fi ^ F2 \ 
OF\QF\Fi-F2\N{Fi,...,F„)\xi 

A rule definition R is preceded by a keyword indicating whether the interpreta- 
tion is maximal or minimal. Maximal rules define safety properties (nothing bad 
ever happens), while minimal rules define liveness properties (something good 
eventually happens). For us, the difference only becomes important when eval- 
uating formulas at the boundaries of a trace. To understand how this works it 
suffices to say here that monitored rules evolve as new events are appearing. As- 
sume that the end of the trace has been reached (we are beyond the last event) 
and a monitored formula F has evolved to F'. Then all applications in F' of 
maximal fix-point rules will evaluate to true, since they represent safety proper- 
ties that apparently have been satisfied throughout the trace, while applications 
of minimal fix-point rules will evaluate to false, indicating that some event did 
not happen. 

The rule parameters are typed and can either be a formula of type Form , or 
of a primitive type such as int, long, float , etc., or any other composite types such 
as Set , List , etc.. The body of a rule (or monitor) is a boolean valued formula 
of the syntactic category Form (with meta- variables F, etc.). Any recursive call 
on a rule must be strictly guarded by a temporal operator. The propositions of 
this logic are boolean expressions over fields of event. Formulas are composed 
using standard propositional logic operators together with a next-state operator 
(QF), a previous-state operator (Q F), and a concatenation-operator (Fi ■ F2). 
Finally, rules can be applied and their arguments must be type correct. That 
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is, an argument of type Form can be any formula, with the restriction that if 
the argument is an expression, it must be of boolean type. An argument of 
a primitive type must be an expression of that type. Arguments can be referred 
to within the rule body {xi). 

In what follows, a rule N of the form 

j max l min j A(Form /i, . . . , Form fm,Ti pi, . . . ,T„ p„) = B, 

where /i , . . . /m are arguments of type Form and pi, . . .p„ are arguments of 
primitive type, is written in short as: I max I min ) A ( Form f,Tp) — B, where / and 
p represent tuples of type Form and T respectively. Without loss of generality, 
in the above rule we assume that all the arguments of type Form appear first. 



Semantics. An execution trace ct is a finite sequence of events a = S 1 S 2 . . . s„, 
where |cr| = n is the length of the trace. The i’th event Si of a trace cr is denoted 
by u{i). The term ctI*’-!] denotes the sub-trace of a from position i to position j, 
both positions included; if f > j then denotes the empty trace. Given a trace 
cr and a specification D O, satisfaction is defined as follows: 



cr 1= L» O iff V (mon N = F) £ O . a,l F 

That is, a trace satisfies a specification if the trace, observed from position 1 (the 
first state), satisfies each monitored formula. The definition of the satisfaction 
relation |=£) C ( Trace x natl x Form , for a set of rule definitions D. is presented 
below, where 0 < f < n-l- 1 for some trace a = S 1 S 2 ■ ■ ■ s„. Note that the position 
of a trace can become 0 (before the first state) when going backwards, and can 
become n -I- 1 (after the last state) when going forwards, both cases causing rule 
applications to evaluate to either true if maximal or false if minimal, without 
considering the body of the rules at that point. 



fj, i 


\=D 


cr, i 




cr, i 


|=D 


cr, i 




cr, i 


\=D 


O’, i 


|=D 


(7, i 


\=D 



expression 

true 

-^F 

Fi A F 2 
OF 
OF 
Fi ■ F2 



a, i \=D N{F, P) 



iff 

iff 

iff 

iff 

iff 

iff 

iff 



iff 



1 < i < \(j\ and evaluate (expression) (a (i)) == true 
a,i false 

c, i F 

a, i \=D Fi and a, i \=d F 2 
i < \a\ and a,i + 1 \=d F 
1 < i and a,i — 1 \=n F 
3j s.t. i < i < |cr| -I- 1 and \=d Fi 

and 1 \=u F 2 

’ if 1 < i < |(j| then: 

a,i \=D B[f i—>F,pi—> evaluate(P)(a(i))] 

' where (A ( Form f,Tp) = B) £ D 
otherwise, if i — 0 ot i = \a\ + 1 then: 
rule A is defined as max in D 



An expression (a proposition) is evaluated at the current event in case the posi- 
tion i is within the trace (1 < f < n). In the boundary cases (t = 0 and i = n-l- 1) 
a proposition evaluates to false. Propositional operators have their standard se- 
mantics in all positions. A next-time formula OF evaluates to true if the current 
position is not beyond the last event and F holds in the next position. Dually 
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for the previous-time formula. The concatenation formula F\ ■ F 2 is true if the 
trace a can be split into two sub-traces a = a\a 2 , such that Fi is true on cri, 
observed from the current position i, and F 2 is true on ct 2 (ignoring ui, and 
thereby limiting the scope of past time operators). Applying a rule within the 
trace (positions 1 . . . n) consists of replacing the call with the right-hand side of 
the definition, substituting arguments for formal parameters; if an argument is 
of primitive type its evaluation in the current state is substituted for the asso- 
ciated formal parameter of the rule, thereby capturing a desired freeze variable 
semantics. 



3.2 The Monitoring Algorithm 

We briefly describe the computation mechanism used to check if an Eagle 
formula is satisfied by a sequence of events. We assume that the propositions or 
the expressions of an Eagle formula are specified with respect to the fields of 
the event record. At every event the algorithm evaluates the monitored formula 
on the event and generates another formula. At the end of the event sequence, 
the value of the evolved formula is determined; if the value is true the formula 
is satisfied by the event sequence, otherwise, the formula is violated. 

Formally, the evaluation of a formula F at an event s = a(i) results 
in an another formula F' = eval(F,s) with the property that a,i |= E if 
and only if tr, f -|- 1 ^ E'. At the end of the trace we compute the boolean 
function value(F), where E is the evolved formula, such that value (F) is 
true if and only if cr, |tj| -|- 1 \= F and false otherwise. Thus for a given 
trace cr = siS 2 ...s„ and an Eagle formula E, cr satisfies E if and only if 
value{eval{. . . eval{eval{F, si), S 2 ) . . . , Sn)) = true. The details of the algorithm 
can be found in [4] which gives the definition of the functions eval and value along 
with two other auxiliary functions update and init. The definition of these four 
functions forms the calculus of Eagle. For this paper, to help in understanding, 
we describe the algorithm informally through an example. 

Suppose we want to monitor the following specification, described in Section 3 

max Always ( Form E) = E A OAlways(E) 

min EvTimedLogout (string fc, double t, double 5) — {time — t < S) 

A{{action = logout A userid = fc) V OEvTimedLogout(fc, t, <5)) 

mon M 3 = Always ((action = login) — + EvTimedLogout (nser/d, time, 100)) 

against the sequence of 2 events ei = {userid = "Bob", action = login, time = 
17.0}, 62 = {userid = "Bob", action = logout, time = 150.0}. At the first event 
the formula M 3 gets modified as follows: 

eval{M 3 , ei) = EvTimedLogout("Bob", 17.0, 100) A 

Always ((action = login) ^ EvTimedLogout (nser/d, time, 100)) 

Note that the relevant summary of the event, involving the user id "Bob" and 
the timestamp 17.0 has got assimilated into the modified formula. At the second 
event the predicate {time — t < 6) gets instantiated to (150.0— 17.0 < 100) which 
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is false. Hence the whole formula becomes false, indicating that the two-event 
trace violates the property. 

One point which is worth stressing on is that the logic Eagle has a finite 
trace semantics. The monitoring algorithm as described above can determine the 
satisfaction or the violation of a formula at the end of a trace only. However, 
in intrusion detection, end of trace makes no sense as the sequence of events 
can be theoretically infinite. In that situation we want to raise an alarm as 
soon as a property is violated. This is done by checking after every event if the 
formula becomes unsatisfiable. Checking unsatisfiability of a formula in Eagle is 
undecidable as it involves data- values. However, note that it is always possible to 
write a formula, corresponding to the absence of an attack, such that, whenever 
the attack pattern appears in the event sequence, the formula becomes false. 
The reason behind this is that we can always specify an attack pattern by a 
formula (j) such that 4>, when evaluated over a sequence of events representing 
the pattern becomes true. This is called specifying-bad prefixes [19]. Once we 
have the attack pattern specification in terms of 4>, we can specify the safe 
behavior of the system as □(->^). Note that this formula becomes false (hence 
unsatisfiable) whenever a sequence of events representing the attack is detected. 
Hence, checking unsatisfiability for the evaluation of this formula at any point 
simply reduces to checking if the evaluated formula is false. 

3.3 Eagle Flier: Monitoring Engine 

We use the monitoring engine Eagle Flier to implement our intrusion de- 
tection framework, called Monid. The engine Eagle Flier, written in Java, 
is available as a library. The library provides two basic methods that can be 
called by any client program for the purpose of monitoring. The first method 
parse takes a file containing a specification involving several monitors (sets of 
monitored formulas) written in Eagle and compiles them internally into data 
structures representing monitors. After compilation, the client program calls the 
method eval iteratively for every event. This call internally modifies the mon- 
itors according to the definition of eval in Subsection 3.2. If at any step the 
monitored formulas become false, an error message is printed or a pre-specified 
method is invoked to take a corrective measure. 

4 Example Attack Specifications 

In this section, we present a few examples of how Eagle can be used to specify 
formulas that correspond to desirable properties of execution traces of a system 
being monitored. An intrusion or an attack in this context is a trace that violates 
this specification. We draw our examples from real-world attacks to showcase the 
applicability of our framework. These examples highlight the expressive power of 
our formalism, as well as exemplify the various features of Eagle. Moreover, we 
believe that many attack signatures in practice can be expressed using templates 
of our examples with minor modifications. In all the examples we use the rule 
Always defined in Section. 3. 
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Smurf Attacks 

The first attack we describe is the Smurf IP Denial of Service (DoS) attack. 
An attacker creates a forged ICMP echo request message (also called a “ping” 
packet) with the victim’s name as the sender and sets the destination IP address 
to a broadcast IP address. This attack can result in a large amount of ICMP 
echo reply packets being sent from broadcast hosts that respond to the request, 
to the victim, which can cause network congestion or outages. 

In order to detect this attack, we need to look at network events from a log 
created by a network auditing tool such as tcpdump. The formula for the absence 
of this attack is given below: 

majc Attack)) = {type = “ICMP”) A isBroadcast(ip) 
mon SmurfSafety = Always (^Attack))) 

In the above example, the record schema of an event contains the type field 
that corresponds to the type of the network packet and the field ip that cor- 
responds to the return IP address of a network packet. In the specification, we 
first specify the attack pattern by the rule Attack that checks if the type of 
the packet is “ICMP” and the destination address of the packet is a broadcast 
IP address {is Broadcast), where isBroadcast is a predicate over the event which 
checks if the last two bytes of the IP address provided as argument are 0 or 255. 
Then a good behavior of the system with respect to this attack can be stated as 
“Always there is no attack” . 



Cookie- Stealing Scenario 

The next example describes what is called the “cookie-stealing” attack. In order 
to monitor this attack we need to look at a web-server (application-level) log 
that contains a record of all sessions that the server participates in, along with 
session-specific state information. 

A cookie is a session-tracking mechanism issued by a web-application server 
to a web-client and store client-specific session information. Clients automatically 
include these cookies that can act as authentication tokens in their requests. In 
this example we assume that a session is identified by its IP address. An attack 
occurs when a malicious user hijacks a session by reusing an old cookie issued to 
a different IP address. The formula below asserts that a particular cookie must 
always be used by the same IP address. 

min SafeUse (string c,int i) = {{name = c) {ip = *)) A 0 SafeUse(c, i) 
mon CookieSafe = Always(Saf eUse(name, ip)) 

A trace that violates this formula therefore encodes a cookie-stealing attack. 
In the above example, the record schema of an event contains the name field 
which corresponds to name of the cookie, and the ip field that corresponds to 
the IP address of the client using the cookie. The parameterized rule SafeUse 
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checks whether the association between a particular cookie identified by the 
cookie name and an IP address (specified as arguments) is the same as this 
association in the past. This example highlights the use of value-binding and the 
previous operator to describe history-based intrusion signatures. 



Multi-domain Buffer Overflows 

The next example illustrates how we can combine information about events 
from different logs in a cross-domain intrusion detection exercise. This scenario 
examines both web-server’s access logs, as well as network logs to infer when 
a buffer-overflow attack has been attempted against the server. Network packets 
are analyzed, looking for binary data. Subsequently, the web-server’s access logs 
are checked to see if a matching event can be found, where the web-server closes 
the connection successfully after receiving some binary data. If no matching log 
record is found, within a specific timeout, then the buffer overflow attack was 
successful and the web-server is now executing the attackers code. This example 
is specified by the formula shown next. 



min EventuallyClosed(long t,long d, long il,long i2) = {time — t< d)A 
{{ipl = il A ip2 = i2 A log = web A type = closed)^/ 

O EventuallyClosed(t, d, il, i2)) 
mon BufferSafe = Always((/o(; = network A type = binary) 

EventuallyClosed(time, 100, ipl , ip2)) 

The record schema for an event contains the log field which indicates the name 
of the log to which the event belongs, the type field which can be binary, closed, 
etc., the time field representing the time at which the event occurred, the ipl field 
representing the source IP address, and the ip2 representing the destination IP 
address. In the rule EventuallyClosed, the arguments t, d, il, and i2 represent 
the time at which the rule is invoked, the timeout period, the source IP address, 
and the destination IP address, respectively. The rule EventuallyClosed asserts 
that eventually within time d the connection involving IP addresses il and i2 
must get closed. Finally, the monitor BufferSafe states that it is always the case 
that if there is a event of binary access in the network log then eventually within 
time 100 there must be a matching event in the web-server log that denotes 
the closing of the connection. Here a connection is identified by the source and 
destination IP addresses. 



Password Guessing Attack 

The next example illustrates the ability of Eagle to collect statistics at runtime 
to detect a potential intrusion. In the password-guessing attack, an unauthorized 
user uses the telnet program to attempt to login into a machine over a network. 
If a user is allowed to guess an arbitrary number of passwords for a given user- 
name, it is only a matter of time before the password is broken. Most systems 
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terminate a telnet session if a user makes more than three invalid password 
guesses over a short-time period. Some systems restrict the total number of 
invalid login attempts over the course of a longer time-period to prevent an 
attacker from succeeding by initiating multiple short sessions. 

In order to detect this attack, we need to have access to the host’s audit logs. 
On Solaris machines for example, auditing can be turned on by running Sun’s 
Basic Security Monitoring (BSM) software. In order to encode this attack, we 
present a template that can be reused for any signature that specifies a threshold 
frequency of events of interest in a trace, which when exceeded constitutes an 
attack: 

max Failure() = {type — login) A ^success 

max Guess(long i. Form F) = {ip = i) A Failure() 

max Counter (long t, long d,int c, long i, int C) = {time — t < d) 

— + ((Guess(i) — > (c < C A OCounter(t, d,c+ 1, i, C))) 
A(^Guess(i) — > Counter(t, d, c, i, C))) 
mon PassGuessSaf e = Always(Failure() Counter(time, 300, 1, ip, 3)) 

In the rule Counter, the arguments t, d, c, i, and C represent the rule invoca- 
tion time, the timeout period, the current number of unsuccessful-guesses count, 
the source IP address doing the guess, and the threshold count. An attack occurs 
when the number-of-guess count c from the IP address i exceeds the threshold 
count C within the timeout period d. Whenever there is a Failure() in login, 
the parameterized rule Counter starts with the initial count set to 1. For every 
occurrence of an event, indicating login- failure from the same IP address within 
the timeout time d, the number-of-guess count is increased by one. The rule 
Counter also checks if within time d whether c exceeds C; in which case the 
whole rule becomes false indicating an attack. The monitor PassGuessSaf e as- 
serts that whenever there is a failure of login from an IP address then eventually 
within time 300 the number of login-failures from the same IP address must be 
less than or equal to 3. 

Port- Sweep Attack 

The Port-sweep attack is the most sophisticated example in this section. A port 
sweep is a surveillance scan through many ports on a single network host. Each 
port scan is essentially a message sent by the attacker to the victim’s port and 
elicits a response from the victim that indicates the port’s status. The aim of 
the attacker is to determine which services are supported on the host, and use 
this information to exploit vulnerabilities in these services in the future. Port 
scans may be legitimate, when a client is trying to determine if a service is being 
offered. However, when the number of port scans exceeds a certain threshold 
within a short time-period, the victim machine can assume that the scans are 
malicious. In order to detect this attack, once again, we need to include a time- 
period and a frequency explicitly in our formula, and can use the template from 
the previous example: 




372 Prasad Naldurg et al. 



max NewPort(long il,long i2. Set S) = (il = ipl) A (i2 = ip2) A {port ^ S) 
max Counter (long t, long d, int c, long il, long i2. Set S. int C) = {time — t < d) ^ 
((NewPort(il, i2, S) {c < C A OCounter(t, d, c + 1, il, V2, S U {port}, C))) 
A(^NewPort(il, *2, S) ^ d, c, il, i2, S', C))) 

mon PortScanSaf e = Always(Counter(time, 100, 1, ipl , ip2, {port}, 10)) 

As before, the arguments t, d, c and C in the Counter rule serve the same 
purpose as place holders for the initial time, the timeout period, the frequency 
count, and the threshold count. The parameterized Counter rule asserts that 
the number of port scans observed in a tcpdump record between a source and 
destination IP (il and i2) address pair never exceeds a certain threshold C 
within time d. Note that in the rule Counter we add every new port number 
scanned to the set S of all port numbers (involving il and i2) that are scanned 
within time d. The rule NewPort checks if the port number, involved in any 
communication between the IP addresses il and i2, exists in the set S of all port 
numbers (involved in all communications between il and i2) within the timeout 
period d. This example shows how we can use Eagle to collect statistics by 
using a rich data-structure such as Set . 

5 Implementation and Evaluation 

5.1 Monid: Monitoring Based Intrusion Detection Tool 

The intrusion detection tool, Monid, is designed to operate in both online and 
offline fashion. In the online mode, Monid runs as a server that receives streams 
of events from various sources. To generate these events, the different logging 
modules are instrumented so that they filter and send relevant events to the 
server. On receiving various events, the server merges them in increasing order 
of timestamps and generates a single event-stream, which is passed through 
a filter to get a projection of the events that are required for monitoring. The 
filtered event stream is fed to the Eagle Elier to see if the event stream violates 
the normal behavior of the system specified as a set of Eagle formulas. Note 
that Eagle Flier never stores the event stream while monitoring; instead it 
collects the essential facts and assimilates them into the monitored formulas by 
transforming them into new formulas. This enables us to use Eagle Flier for 
online monitoring. In the offline mode, Monid reads various log files and sends 
an event corresponding each log entry to the server. The server then processes the 
event stream as before to detect intrusion. We perform most of our experiments 
in offline mode. 



5.2 Evaluation 

We test our Monid tool with the standard DARPA Intrusion Detection Eval- 
uation data set [13] to study the overheads and explore the expressive power 



A Temporal Logic Based Framework for Intrusion Detection 373 





Event Number Event Number 

Fig. 2. Performance Overhead of Fig. 3. Performance Overhead of 
Port-Sweep Attack Password- Guess Attack 

of our logic with real-world examples. In our experiments with Monid, we fo- 
cus on the data sets provided in the 1998 offline Intrusion Detection Evaluation 
plan [13]. This data set focuses on UNIX workstations. The experimental setup 
simulates a military base with a private network marked as “Inside” connected 
to the “Outside” world through a Cisco AGS-h router. Two types of logs are 
available for analysis. The tcpdump logs were collected by running tcpdump on 
this connecting router. This data contains the contents of every packet trans- 
mitted between computers inside and outside of the military base, and gives us 
network sessions of complete TCP/IP connections. The sessions were designed to 
reflect (statistically) traffic seen on military bases and contain explicit examples 
of different real attacks. 

The other data available is from the Sun Basic Security Module (BSM) from 
the host pascal, which was the victim of the simulated attacks, located on the 
“Inside” network. This data contains audit information describing system calls 
made to the Solaris kernel. 

We implemented and tested our tool against the smurf, port-sweep and 
password-guessing as discussed in Section 4, of which we report the results of last 
two experiments due to space limitation. We do not repeat the details of these 
attacks here. We ran our tool on a 2.0 GHz Pentium M laptop with 1GB RAM, 
simulating the behavior of a dedicated-monitor that passively observes traffic on 
the “Inside” network and processes events from our victim host offline. The aim 
of our experiments is to demonstrate that the tool can detect intrusions, and the 
monitoring and processing overheads of our prototype tool are very low. 

Our experiments detected 5 password-guess attack and 2 port-sweep at- 
tack in the logs. The performance overheads for monitoring the Port-Sweep and 
Password-Attacks are given in Figure 2 and 3, respectively. The X-axis in both 
graphs shows the number of events we are monitoring, as they are obtained 
from our logs. Each data point is the average overhead calculated for intervals 
of 10 and 1000 events respectively. The Y-axis plots the ratio between the time 
spent by the monitor vs. the time between the generation of the events in the 
actual log. As long as this ratio is less than 1, our monitoring is feasible. The 
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results, show that the average overhead, is around 0.009 for Port-Sweep attacks 
and 0.016 for Password-Guessing attacks, suggesting that online mode is feasible 
and efficient. 

6 Conclusion 

We have proposed a framework for intrusion detection using a temporal logic 
approach. In contrast to other such temporal logic based approaches [16], we 
use an expressively rich logic in which one can express both signature based 
and simple anamoly based attack specifications. We automatically monitor such 
attack specifications with respect to the system execution. An intrusion is de- 
tected when the observed execution violates the formula being monitored. We 
demonstrate this approach by specifying formulas for detecting several types of 
well-known attacks, and by testing a prototype implementation of our monitor- 
ing algorithm over large event-logs made available by DARPA for evaluation 
purposes. We believe that our examples are generic and can be used as template 
for specifying a large number of other attacks. 

Our approach opens up several interesting directions for future research. We 
plan to conduct a more systematic performance study and categorize the over- 
heads more precisely. With the aim to exploit the expressiveness of our logic, 
we plan explore the use of ideas introduced in [18, 19] for predicting security 
failures from successful executions in multi-threaded programs. Specifically, in 
addition to monitoring a given specification against the currently observed trace, 
we can also compare the specification with all the traces that correspond to dif- 
ferent interleavings of the same partial order (causality relation) between the 
underlying events. Another problem of interest is to use the distributed moni- 
toring framework introduced in [20] for detecting attacks that involve multiple 
hosts on a network. We believe that our approach can complement existing in- 
trusion detection mechanisms and provide support for more expressive attack 
specifications. 
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